У меня есть crontab, который каждую ночь создает дамп моей базы данных:
20 3 * * * /path/to/dailydump.sh
dailydump.shсодержит:
#!/bin/sh
DATENAME=`date +%Y%m%d`
BASENAME="/path/to/dumps/db_${DATENAME}.sql"
/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME}
Разрешения:
-rwx---r-x 1 ... dailydump.sh
drwxr-xrwx 2 ... dumps
Почему не работает мой cronjob?
Я нахожусь на общем сервере без доступа root. Нет никаких журналов в /var/log/cronили /var/log/syslog. Нет почты в /var/mail/<user_name>или /var/spool/mail/<user_name>(на самом деле нет ничего вообще в /var/mail/и /var/spool/), [email protected]не отправляет никаких сообщений об ошибках и 1 2 * * * /path/to/your/command &>/path/to/mycommand.logне сохраняет никаких файлов журналов. ps -ef | grep cron | grep -v grep?ничего не возвращает. (См.https://serverfault.com/a/449652)
Вся настройка работала нормально, пока я не переместил все файлы на новый домен и не пришлось настроить новый crontab. (Да, я обновил все пути и информацию для входа в базу данных. Я также проверил это несколько раз.) Я работаю с тем же хостинг-провайдером на той же машине, поэтому среда не изменилась.
Любая помощь будет высоко оценена.
"Решение"
Ладно, это очень странно. В справочном центре моего провайдера сказано, что если скрипт, который должен быть выполнен cronjob, находится в защищенном паролем каталоге, мне нужно добавить -auth=user:password -sourceперед путем к скрипту. Поэтому я добавил это (с соответствующей аутентификацией):
20 3 * * * -auth=user:password -source /path/to/dailydump.sh
Результатом стало то, чтоМне было отправлено сообщение об ошибке по электронной почте(так MAILTO=работает), сообщая мне /bin/sh: -=: invalid optionи перечисляя доступные опции. Пример в справочном центре на самом деле не давал физический путь ( /path/to/file), а URL ( http://...), поэтому я удалил authи sourceснова и сохранил crontab, итеперь эта чертова cronjob-задача запускается!!«Файл crontab выглядит точно так же, как и раньше, символ в символ, но теперь он работает без видимых изменений в коде.
Понятия не имею, в чем была проблема, но вставка неправильного кода и его повторное удаление сработали. o_O Похоже, что cronjob на самом деледелалзапускается все время (потому что когда он этого не делает, он, очевидно, выдает ошибку), только то, что онНичего не сделал!Очень загадочно. Если кто-нибудь сможет мне это объяснить (воспроизводимым образом), я предложу вознаграждение в 200 и выдам его (после необходимого ожидания в два дня).
Кроме того, @chaos дал мне другое решение, полностью избегая скрипта оболочки и позволяя cron напрямую создавать дамп базы данных (см. комментарии к его ответу ниже):
20 3 * * * /usr/bin/mysqldump -hhost -uимя_пользователя -pпароль имя_базы_данных > /path/to/dumps/db_$(date +\%Y\%m\%d).sql
Только не забудьте экранировать знаки процента, иначе скрипт обнаружит «неожиданный EOF».
Спасибо всем за помощь. Я снова многому научился (хотя и не понял, что здесь было не так).
решение1
Чтобы убедиться, что cronдемон запущен и соблюдает crontab, вы можете провести небольшой тест. Отредактируйте свой crontabфайл, добавив следующую запись:
* * * * * /bin/date >>/tmp/test
Через минуту проверьте файл /tmp/test. Если файла нет, то демон, скорее всего, не запущен. Если это так, я бы связался со службой поддержки провайдера.
Редактировать:
Чтобы определить среду в экземпляре cron, необходимо:
* * * * * /usr/bin/id >>/tmp/test
* * * * * /usr/bin/env >>/tmp/test
Теперь посмотрим содержимое файла.
решение2
- Запустите скрипт напрямую и проверьте, работает ли он.
- Некоторые переменные среды оболочки могут быть недоступны при запуске скрипта под crontab в зависимости от того, как вы настроили скрипт.
Попробуйте изменить скрипт, чтобы проверить, связана ли проблема с переменными среды:
sh --login -c "/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME} > /path/to/LogFile.txt 2>&1"