У меня есть система Debian GNU / Linux 4.0 (которая не может быть обновлена), работающая круглосуточно. У него есть несколько заданий в /etc/cron.daily, включая наши сценарии резервного копирования. Несколько недель назад я заметил, что скрипт резервного копирования не запускается регулярно.
Сегодня утром я запустил каталог cron вручную (nice run-parts --report /etc/cron.daily) что видно в обоих /etc/anacrontab и /etc/crontab. Я получил электронное письмо для logwatch, но не для других вакансий. Наши сценарии резервного копирования, в частности, имеют большой объем вывода и занимают несколько часов. Я пытался переставить рабочие места в /etc/cron.daily, без эффекта, и недавно я удалил anacron, так как этот ящик "никогда" не должен простаивать.
Кажется, что выполнение любого из заданий по отдельности работает нормально. Я только что добавил сценарий резервного копирования в /etc/crontab вручную, чтобы проверить, правильно ли он работает.
Есть ли у кого-нибудь другие предложения?
Проблема в том, что Debian не позволяет '.' в имени файла задания cron, хранящегося в /etc/cron.(d|daily|weekly|monthly). Удалите ".", И работа будет выполнена нормально.
Отображаются ли в журналах cron какие-либо ошибки или они выполняются в указанное время?
Что произойдет, если вы посмотрите, как процессы выполняются в то время, в которое они должны быть запущены (то есть, если они запланированы на 16:00, как система выглядит в списке процессов и регистрируется в 4:01?
Глупый вопрос, но вы сказали, что получаете электронные письма от logwatch, но не о других вакансиях. Вы дважды проверяли, что задания действительно не выполняются, а не проблема связи с электронными письмами, уведомляющими вас о выполненных заданиях?
Выполняются ли задания в надлежащем пользовательском контексте с разрешениями на выполнение необходимых действий? Они терпят неудачу только иногда, но не другие?
Можете ли вы найти что-нибудь, что происходит в те моменты, когда они выходят из строя, но не в других случаях (вы сказали, что это система без простоев ... делает ли она что-то, где сценарии перекрываются, поэтому они не могут завершиться? Или есть процессы, которые будут заблокировать их?)
В системе настроено что-нибудь, что убивает процессы на определенном уровне нагрузки? Сторожевые таймеры и т. Д. Могут убить процесс, если нагрузка слишком велика или квота процессора / оперативной памяти становится слишком высокой и т. Д. Или система перестает отвечать. Еще одна причина посмотреть, может ли кто-нибудь следить за ним через сеанс ssh в момент, когда сервер должен выполнять задание.
Барт рассказал обо всем, что я искал, кроме, может быть, места на диске. Когда все рабочие места объединяются, и им не хватает места? Что-то еще происходит в это время, что может вызвать большую временную нагрузку на дисковое пространство?
Еще одна вещь, которую вы можете попробовать, - это запустить их в другое время. Либо сразу, скажем 5:00, либо индивидуально, 4:00 / 4:30 / 5:00 / 5:30 и т. Д.
другое дело - окружающая среда. скрипты уже успешно запускаются через cron? среда cron может отличаться от вашей среды тестирования (PATH, ...). Можно ли добавить логирование в ваши сценарии резервного копирования с помощью команд logger или echo?
У меня тоже была такая же проблема с '.' в именах скриптов. Удаление любых "." в имени скрипта решена моя проблема (даже расширение ".sh"!)
Параметры --lsbsysinit или --regex для run-parts позволяют изменить имена файлов, которые считаются допустимыми.