Вариантов может быть несколько. Давайте по порядку разберемся с каждым из них.
Во-первых, cron передает минимальный набор переменных окружения вашим скриптам. Что бы протестировать работает / не работает, можно сделать липовую задачу вроде этой:
* * * * * env > /tmp/env.output
Остается только подождать минуту пока этот файл /tmp/env.output создатся. Как только файл будет создан, уберите эту задачу из крона. И сравните содержимое этого файла с выводом команды env в терминале:
env
Один из типичных "ага, вот оно!" моментов связан с разными значениями переменной окружения PATH. Вполне возможно что ваш скрипт использует какую то команду mycommand, которая вызывается по пути /opt/somepath/bin и которая добавляется к переменной PATH. Поэтому переменная PATH как она задана у вас в шеле может перетираться при вызове скрипта из крона. Что бы избежать такой проблемы, имеет смысл жестко зафиксировать PATH в кроне перед вызовом скрипта:
#!/bin/bash
PATH=/opt/somepath/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# и дальше идет ваш скрипт
Некоторые люди рекомендуют использовать абсолютные пути при вызове команд из crontab, но на мой взгляд это не критично. Главное убедиться что переменная PATH не перезаписывается.
Еще можно убедиться что ваш крон работает. Он должен присутствовать в дереве процессов:
ps -ef | grep cron | grep -v grep
И вывод должен быть примерно таким:
root 1121 1 0 Sep26 ? 00:00:08 cron
Либо таким:
root 1121 1 0 Sep26 ? 00:00:08 crond
Если ничего нет, то запустите демон:
/sbin/service cron start
Либо
/sbin/service crond start
Еще одним вариантом почему не отрабатывают задания в кронтабе может быть истекший пароль. Убедитесь что в /var/log/messages нет сообщений на этот счет
grep -i "auth" /var/log/messages
Если пароль все таки истек, то будет сообщение вроде такого:
(username) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)
Решение проблемы в этом случае простое - задать новый пароль через passwd.
