*/5 * * * * my command
Эта запись работает, но каждые 5 минут она выполняется дважды, почему?
В /var/log/cron он показывает:
Jun 16 22:20:01 Test CROND[12512]: (root) CMD (my command)
Jun 16 22:20:01 Test CROND[12516]: (root) CMD (my command)
Так что это не от двух пользователей.
Он вводится только один раз с crontab -e -u root. Команда является командой php.
Ничто в описании не дает причины для его выполнения дважды. Посмотрите в другое место.
Если вы выполняете оболочку script, добавьте whoami и date в файл журнала. Вы должны быть в состоянии выяснить причину.
Введите ps -A, убедитесь, что crond не работает дважды.
wget в crontab часто имеет ограничение в 15 минут. В нашем случае это было именно так, и после этих 15 минут работа заканчивается таймаутом, а затем снова запускается снова. Итак, решение этой задачи состояло в том, чтобы создать cronjob в crontab примерно так:
1 2 * * * root wget --read-timeout=3600 -O - 'http://cron-job-url' >/dev/null 2>&1
... вместо
1 2 * * * root wget -O - 'http://cron-job-url' >/dev/null 2>&1
Итак, wget - это вещь. Значение 3600 = 1 час. Или больше, если вам нужно!
Если это команда для установленного приложения, возможно, она уже добавила ту же запись в /etc/crontab или /etc/cron.d/<something>.
Я подтверждаю, что мой cron также работает дважды...
Jul 24 14:40:01 localhost cron[2713]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:41:01 localhost cron[9481]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:41:01 localhost cron[10724]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:42:01 localhost cron[20380]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:42:01 localhost cron[20832]: (root) CMD (/etc/apache2/generator/reloader.do)
Мой crontab
grep -R/var/spool/-e reloader
/var/spool/cron/crontabs/root:* * * * * /etc/apache2/generator/reloader.do
вывод:
whoami
date
------
выход:
root
root
Tue Jul 24 14:46:02 CEST 2012
---------
Tue Jul 24 14:46:03 CEST 2012
---------
Мое текущее обходное решение:
if [ -f /etc/apache2/generator/reloader.lock ]
then
exit
fi
touch /etc/apache2/generator/reloader.lock
/etc/apache2/generator/reloader
rm /etc/apache2/generator/reloader.lock
Но это не ответ, почему это происходит...
Система - gentoo Cron - vixie-cron
часть вывода ps aux wwf (запущенная внутри задачи cron)
root 10843 0.0 0.0 16480 560 ? Ss Jun06 0:01 /usr/sbin/cron
root 29797 0.0 0.0 25020 964 ? S 15:08 0:00 \_ /usr/sbin/cron
root 29799 0.0 0.0 9188 1228 ? Ss 15:08 0:00 \_ /bin/bash /etc/apache2/generator/reloader
root 29822 0.0 0.0 14800 988 ? R 15:08 0:00 \_ ps aux wwf
------
root 8215 0.0 0.0 16480 836 ? Ss 14:23 0:00 /usr/sbin/cron
root 31419 0.0 0.0 25020 968 ? S 15:08 0:00 \_ /usr/sbin/cron
root 31423 0.0 0.0 9188 1228 ? Ss 15:08 0:00 \_ /bin/bash /etc/apache2/generator/reloader
root 31431 0.0 0.0 14804 1004 ? R 15:08 0:00 \_ ps aux wwf
EDIT:
Я заметил, что один из отчетов процесса cron Jun06 в качестве даты начала (сегодня это Jun24)
root 10843 0.0 0.0 16480 560 ? Ss Jun06 0:01 /usr/sbin/cron
root 8215 0.0 0.0 16480 836 ? Ss 14:23 0:00 /usr/sbin/cron
Отчет о втором процессе корректно (перезапуск сервера составляет ~ 40 минут - я перезапустил его недавно) Одна важная информация - это V-сервер, запущенный на хост-машине.
Независимо от того, что я делаю (/etc/init.d/vixie-cron restart), он начинается с того же PID
РЕШИТЬ:
Я нашел причину. Один V-сервер запускался дважды, с другим контекстом. Возможное объяснение: кто-то изменил контекст во время работы машины, и в результате не все процессы были убиты, а что еще - они повлияли на новый экземпляр vserver (контекст 303 и 3031):
root 10843 3031 developer 0.0 0.0 16480 560 ? Ss Jun06 0:01 /usr/sbin/cron
root 16509 303 developer 0.0 0.0 16480 836 ? Ss 15:18 0:00 /usr/sbin/cron
У меня TERM старый процесс, и проблема решена.
Конечно, это не запись crontab, которая заставляет его работать дважды. Самый быстрый способ узнать, что происходит, - добавить некоторую отладку в задание cron script. Если вы ничего не сделаете, то по умолчанию вывод cron будет отправлен по электронной почте на [email protected] (если вы не настроили его на другое), поэтому, предположив, что у вас есть root-доступ, добавьте некоторую отладочную информацию в script, например:
echo "Script starting"
date
whoami
и посмотрите на результат. Это поможет вам понять, как это вызывается дважды.
У меня была одна и та же проблема, и в моем случае я дважды инициализировал службу cron по ошибке. После того, как я остановил cron # /etc/init.d/crond stop и снова начал его # /etc/init.d/crond start, он работал отлично.
Я надеюсь, что это может помочь кому угодно.
Похоже, у вас есть два коллажа, один с PID 12512 и один с PID 12516.
Я использую OpenWrt.
У меня такая же проблема, но у меня есть только один cron: ps | grep crond:
31447 root 1508 S /usr/sbin/crond -c /etc/crontabs -l 8
31454 root 1500 S sh -c ps | grep crond
31456 root 1496 S grep crond
logread | grep cron
May 27 13:15:01 decibox cron.info crond[31447]: crond: USER root pid 1594 cmd /root/check_connect.php.sh
May 27 13:20:01 decibox cron.info crond[31447]: crond: USER root pid 2103 cmd /root/check_connect.php.sh
May 27 13:20:01 decibox cron.info crond[31447]: crond: USER root pid 2325 cmd /root/check_connect.php.sh
May 27 13:25:01 decibox cron.info crond[31447]: crond: USER root pid 2880 cmd /root/check_connect.php.sh
У меня была такая же проблема из-за двойной записи в файле conf:
# grep /syslog /etc/rsyslog.conf /etc/rsyslog.d/50-default.conf
/etc/rsyslog.conf:*.*;auth,authpriv,kern,mail.none -/var/log/syslog
/etc/rsyslog.d/50-default.conf:*.*;auth,authpriv,kern,mail.none -/var/log/syslog
Четко комментируя один из 2 решает проблему
Запуск PS -A | grep cron, убийство всех рабочих мест не помогло в моем случае. Проблема заключалась в том, что после уничтожения всех заданий cron и повторного запуска только с одним демоном cron я мог запустить два задания cron с одного и того же родительского PPID cron - одно с /bin/bash - другое с /bin/sh
Решением было перезагрузить сервер.
Это происходило несколько раз, в разных ОС - centos 6 и redhat 7. Обычно после онлайн обновления ОС без перезагрузки.
Как кто-то сказал - возможно, какой-то другой контекст.
Я видел одну статью в сети с такими же процессами, одну с /bin/bash, другую с /bin/sh в одно и то же время - я подумал, даааа - это мой случай - но нет, парень даже не задумывался первопричина такого странного поведения, просто начал писать некоторую логику сценария, чтобы завершить второй процесс, что на самом деле не является решением.
Кстати, пс -A | grep cron также перечислит все дочерние элементы cron - обычные задания cron, больше процессов cron не означает, что это больше демонов cron, может быть только один демон, а другие - дочерние.
ps -ef | grep cron с другой стороны перечисляет только один - почему? Поскольку ps -ef перечисляет дочерние элементы как CROND - чтобы заставить их всех делать ps -ef | grep -i cron
Я недавно перешел с vixie-cron на cronie и заметил, что мой корневой crontab был дубликатом моего пользовательского файла crontab.
Выполните/запустите "crontab -e", как от имени пользователя, так и от имени пользователя root, и проверьте файлы, чтобы убедиться, что дублирующиеся команды не выполняются.
Как root:
Как пользователь: $ crontab -e
Если файлы существенно схожи, может быть лучше вставить комментарий "# TEST" в нежелательное содержимое crontab, чтобы избежать удаления символических ссылок или других аномалий перед удалением содержимого файла crontab.