Vesta Control Panel — Forum
Cron suddennly not run
Cron suddennly not run
Post by maniek015 » Sun Aug 21, 2016 5:40 am
Hello.
I have a problem with a CRON. He is suddennly not run. Two days ago all work’s perfectly and I don’t make a changes in the settings server, Vesta or CRON. Now i have in cron.log this error :
Aug 20 19:50:01 xshare cron[491]: (admin) ERROR (Syntax error, this crontab file will be ignored)
Aug 20 19:50:40 xshare cron[10027]: (CRON) INFO (pidfile fd = 3)
Aug 20 19:50:40 xshare cron[10027]: Error: bad day-of-month; while reading crontab for user admin
Aug 20 19:50:40 xshare cron[10027]: (admin) ERROR (Syntax error, this crontab file will be ignored)
Aug 20 19:50:40 xshare cron[10027]: (CRON) INFO (Skipping @reboot jobs — not system startup)
Aug 20 19:52:01 xshare cron[10027]: (admin) RELOAD (crontabs/admin)
Aug 20 19:52:01 xshare cron[10027]: Error: bad day-of-month; while reading crontab for user admin
Aug 20 19:52:01 xshare cron[10027]: (admin) ERROR (Syntax error, this crontab file will be ignored)
Aug 20 19:53:01 xshare cron[10027]: (admin) RELOAD (crontabs/admin)
Aug 20 19:53:01 xshare cron[10027]: Error: bad day-of-month; while reading crontab for user admin
Aug 20 19:53:01 xshare cron[10027]: (admin) ERROR (Syntax error, this crontab file will be ignored)
Aug 20 19:53:26 xshare cron[11498]: (CRON) INFO (pidfile fd = 3)
Aug 20 19:53:26 xshare cron[11498]: Error: bad day-of-month; while reading crontab for user admin
I try a few cron commands.. /php , wget , /use/bin/php and still dont work. Two days ago its work’s..
Please help me find a solution 🙂
Re: Cron suddennly not run
Post by Felix » Sun Aug 21, 2016 7:26 am
Whenever you post some error or you need help, it’s really important for you to be as specific as possible and to provide information like the Operating System you’re using, Vesta version, etc.
I suppose there is something wrong with the admin crontab. Run the following command to display the admin’s crontab and copy/paste here the output, so we can see what’s wrong. Omit any personal information (e.g. email address)
If using Ubuntu
Re: Cron suddennly not run
Post by maniek015 » Sun Aug 21, 2016 7:30 am
Thank’s for reply.
I have a Debian 8.5 with VestaCP 0.9.8-16
# cat /var/spool/cron/crontabs/admin
MAILTO=mateusz.maniecki@gmail.com
15 02 02 * * sudo /usr/local/vesta/bin/v-update-sys-queue disk
15 00 00 * * sudo /usr/local/vesta/bin/v-update-sys-queue traffic
30 03 * * * sudo /usr/local/vesta/bin/v-update-sys-queue webstats
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-queue backup
0 4 * * 1 sudo /usr/local/vesta/bin/v-backup-users
20 00 * * * sudo /usr/local/vesta/bin/v-update-user-stats
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-rrd
5 0 * * * php /home/admin/web/mydomain/public_html/admin/tasks/auto_prune.cron.php >> /dev/null 2>&1
10 0 * * * php /home/admin/web/mydomain/public_html/admin/tasks/create_internal_notifications.cron.php >> /dev/null 2>&1
15 0 * * * php /home/admin/web/mydomain/public_html/admin/tasks/delete_redundant_files.cron.php >> /dev/null 2>&1
25 0 * * * php /home/admin/web/mydomain/public_html/admin/tasks/downgrade_accounts.cron.php >> /dev/null 2>&1
*/5 * * * * php /home/admin/web/mydomain/public_html/admin/tasks/process_file_queue.cron.php >> /dev/null 2>&1
0 1 * * * php /home/admin/web/mydomain/public_html/admin/tasks/create_email_notifications.cron.php >> /dev/null 2>&1
Re: Cron suddennly not run
Post by Felix » Sun Aug 21, 2016 10:52 am
It seems the second entry is wrong. Highlighted and underlined the mistake:
15 00 00 * * sudo /usr/local/vesta/bin/v-update-sys-queue traffic
You’re asking for day 0 of the month, which does not exist. You can check your crontabs with http://crontab.guru/
Moreover I’m not sure if these php statements will work. I think you need to specify the full path to the executable /usr/bin/php (or wherever that is in your distribution) instead of just the php executable
Re: Cron suddennly not run
Post by maniek015 » Sun Aug 21, 2016 11:04 am
I generate this cron with Vesta. Cron with /usr/bin/php don’t work too.
All the Cron job don’t work, not only this
Re: Cron suddennly not run
Post by maniek015 » Sun Aug 21, 2016 11:07 am
Re: Cron suddennly not run
Post by Felix » Sun Aug 21, 2016 2:50 pm
Re: Cron suddennly not run
Post by maniek015 » Sun Aug 21, 2016 3:37 pm
Источник
Подскажите, почему не отрабатывает скрипт в crontab
Добрый день. Есть один скрипт recycle_clean.sh, он запускается вручную успешно и отрабатывает, но вот в /etc/crontab есть такая запись:
И из него почему-то не отрабатывает этот скрипт. Cron вроде запущен, по /etc/init.d/cron status выдает:
Стало быть крон запущен. Подскажите, почему не отрабатывает?
ls -l /root/scripts/recycle_clean.sh
head /root/scripts/recycle_clean.sh
Выложи содержимое скрипта и syslog в момент запуска кроном.
Вангую отсутствие PATH
и пустую строку в конце не забудьте.
Это группа, в ней доменные пользователи. А так, как вы предложили (* * * * *), он же не будет отрабатывать раз в сутки, или будет?
У меня нет такого лога даже: /var/log/crond.log
и пустую строку в конце не забудьте
старообрядцы в треде
Это группа, в ней доменные пользователи. А так, как вы предложили (* * * * *), он же не будет отрабатывать раз в сутки, или будет?
он будет отрабатывать 1440 раз в сутки. Каждую минуту. Ускоряет поиск ошибки в 1440 раз.
Да, таких групп не бывает в Linux’е.
У меня нет такого лога даже: /var/log/crond.log
а что, починили, да? Я не в курсе, vim подставляет самостоятельно. Но может ТС notepad.exe юзает?
Честно говоря, вообще никогда не встречал этой проблемы в реальности, и всегда думал что crontab -e сам всё валидирует и делает, хоть добавляй, хоть не добавляй
Я по мотивам какого-то треда пару лет назад тестировал это и всё работало при любом варианте
А чтобы раз в сутки нужно оставить как было:
Так как там достаточно много данных перемещает скрипт, каждую минуту не успеет.
Честно говоря, вообще никогда не встречал этой проблемы в реальности, и всегда думал что crontab -e сам всё валидирует и делает, хоть добавляй, хоть не добавляй
crontab -e вызывает EDITOR, а уж что делает $EDITOR — я не знаю. У меня это vim. А вот народ ставил mcedit, и жаловался на эту проблему.
Я по мотивам какого-то треда пару лет назад тестировал это и всё работало при любом варианте
строка должна заканчиваться n, иначе это формально не строка, а мусор. Gcc предупреждает, но компиллит. А вот как сейчас crond — я не знаю.
А чтобы раз в сутки нужно оставить как было:
там можно и это, и любое другое валидное время поставить. Сначала минуты, а потом часы. Лучше ставить на пару минут вперёд, что-бы ждать две минуты.
То есть он не отрабатывает потому что не добавлен в
а после создания такого файла и добавления в него строки, аналогичной таковой в /etc/crontab будет автоматически отрабатывать?
То есть он не отрабатывает потому что не добавлен
не. Ты даже НЕ ЗНАЕШЬ, отрабатывается он, или нет. И если нет — то почему. А в том файле это будет написано.
/var/log/crond.log а после создания такого файла
он сам создастся, с ошибками, которые нужно исправить.
и в /var/log/crond.log появилось:
bash: 59: команда не найдена
задумайся, почему именно 59?
echo нужно в начале?
эту строчку в crontab надо вставлять. В консоль вставляй БЕЗ 59 23 * * * root
Да, это была такая папка, после выполнения скрипта вручную. Я ее удалил и все запустил заново, в логе пусто после этого.
Но все равно он не отрабатывал, так как папка должна создаваться каждый день, а они не создавались. Вот только сегодня вручную запустил — тогда создались.
PATH проверил, все вроде ок в ней.
Спасибо! Она мне не помешает! =) Показал другому одмину — говорит что сам крон не работает, а crontab в порядке. Но вроде показывает:
mv: невозможно переместить «/var/share/data_drive/Disk_S/.recycled/current» в «/var/share/data_drive/Disk_S/.recycled/2014-03-05/current»: Кат$
видимо «каталог существует»
mkdir: невозможно создать каталог «/var/share/data_drive/Disk_S/.recycled/current»: Файл существует
надо проверить, потом создавать
[ -d /var/share/data_drive/Disk_S/.recycled/current ] || mkdir /var/share/data_drive/Disk_S/.recycled/current
у вас в самом скрипте ошибки.
Пусть уволится, он не админ.
Да, это после того как я вручную запустил его (скрипт), каталог создался, и при последующем запуске тоже вручную выдалась такая ошибка, так как каталог был. Я его удалил. Но кронтаб все равно не работает, не понимаю почему.
У нас просто все неспешно. =)
Сейчас содержимое /etc/crontab такое:
Но кронтаб все равно не работает, не понимаю почему.
1. исправьте ошибки в скрипте. Вот что вы мне моск полоскаете? У меня сын первоклашка, у него есть работа над ошибками. У вас какая-то альтернативная школа?
2. заведомо рабочий скрипт пропишите в crontab. Потом читайте логи.
Checking periodic command scheduler. done (running).
и что? Да, работает чего-то. У меня куча таких шедулеров. Тоже работают. Что дальше?
Да вот даже простой скрипт
* * * * * root echo ‘Время: ‘ ; date
КУДА он должен его «выполнять»? Откуда он знает, что вы эмулятор терминала где-то внутри Xorg’а запустили?
Команда выполняется, а результата ты тупо НЕ ВИДИШЬ.
SHELL=/bin/bash же указан
блжад. Это то, ЧТО выполняет. А КУДА?
Обычно по дефолту оно в почту срёт. А у тебя MAILTO=. Что значит — в никуда.
Первый раз вижу, чтобы человек «почти осилил crontab», но в тоже время демонстрировал полное непонимание основ.
А 
emulek должен получать молоко за вредность.
Вот попробовал на машине с точно таким же шестым дебианом —
И файл создался. А на моем злосчастном серваке — тишина при точно такой же строке.
Я не очень линуксоид по всяким серверным штукам, только как пользователь — ставлю убунты и переустанавливаю убунты.
А emulek’у я очень благодарен.
Первый раз вижу, чтобы человек «почти осилил crontab», но в тоже время демонстрировал полное непонимание основ.
Увы. С тех пор, как изобрели гугл, это обычная ситуация.
А на моем злосчастном серваке — тишина при точно такой же строке.
дык сделай логгирование, как я выше писал. Должно работать.
Да, куда ты прописываешь-то? И как?
Я просто в /etc/crontab прописал ниже под всем, ну команду touch на другой машине с аналогичным дебианом. А вот на этом серваке — тоже добавил. И не отрабатывает. Крон вроде везде одинаковый. Может его переставить? Просто не хотелось бы перезапускать этот сервак. Но просто перезапуск крона не помогает.
думаешь мне интересно, через какую жопу ты делаешь? Нет.
Просто скрипт же отрабатывает если вручную его запускать. Значит не в нем проблема.
Во-первых, если скрипт при повторном запуске без изменения входных данных может обломаться, то это плохой скрипт: http://ru.wikipedia.org/wiki/Идемпотентность
Во-вторых, настройте почтовую подсистему (достаточно взять какой-нибудь nullmailer, чтобы слал через smtp) и настройте перенаправление почты root-а к себе на ящик (ну, или локально складывать, если на машине нет интернета/доступа к какому-нибудь smtp-серверу). Это будет полезно не только для отладки cron, но и для получения информации по многим системным событиям (smartd руту пишет, например, когда на дисках происходит что-то нехорошее).
В-третьих, чтобы закончить бессмысленные аргументы на тему того, что «cron не работает», посмотрите /var/log/syslog. Там будут строчки типа:
Найдите строчки, которые соответствуют запуску задания с вашим скриптом (они там будут, даже если скрипт обломается).
Источник
Ok so i am no longer getting any errors in /var/log/cron.log. Instead i am getting:
Jul 29 17:00:01 raspberrypi /USR/SBIN/CRON[9460]: (root) CMD (/etc/cron.d/freeduns_update.sh >/dev/null)
Jul 29 17:01:01 raspberrypi /USR/SBIN/CRON[9466]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Jul 29 17:02:01 raspberrypi /USR/SBIN/CRON[9470]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Jul 29 17:03:01 raspberrypi /USR/SBIN/CRON[9474]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Jul 29 17:04:01 raspberrypi /USR/SBIN/CRON[9478]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Jul 29 17:05:01 raspberrypi /USR/SBIN/CRON[9504]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Jul 29 17:05:01 raspberrypi /USR/SBIN/CRON[9505]: (root) CMD (/etc/cron.d/freeduns_update.sh >/dev/null)
Jul 29 17:06:01 raspberrypi /USR/SBIN/CRON[9512]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Jul 29 17:07:01 raspberrypi /USR/SBIN/CRON[9518]: (root) CMD (echo «crontest $(date) $(whoami)» >>/tmp/crontest.txt)
Which i believe means everything is running fine and when i look at /tmp/crontest.txt it is deffinitely writing to it with no problems.
But my ip for the dynamic dns is not updating. Below is my code for /etc/cron.d/freedns_update.sh:
#!/bin/sh
# freedns_update.sh: Update the public IP on freedns.afraid.org only if it has changed.
## Place this script in the cron’s job directory /etc/cron.d and assign the proper permissions
## and owner
## sudo chmod 500 /etc/cron.d/freedns_update.sh
## sudo chown root:root /etc/cron.d/freedns_update.sh
## Add to /etc/crontab to execute on reboot and every 5 minutes
## Edit /etc/crontab and append these two lines:
## @reboot root /etc/cron.d/freedns_update.sh >/dev/null
## */5 * * * * root /etc/cron.d/freedns_update.sh >/dev/null
#Use your own values
DOMAIN=####
HASHKEY=####
UPDATE_URL=»http://freedns.afraid.org/dynamic/update.php?${HASHKEY}»
current_ip=$(wget -q —output-document — http://checkip.dyndns.org | grep -o ‘[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}’)
registered_ip=$(ping -qn -c 1 $DOMAIN | head -n 1 | grep -o ‘[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}’)
if [ «${current_ip}» != «${registered_ip}» ]; then
wget -q —read-timeout=0.0 —waitretry=5 —tries=400 —output-document /dev/null $UPDATE_URL
if [ $? -eq 0 ]; then
echo «$(date +»%b %_d %T») $(hostname) $0: IP address updated on freedns.afraid.org: new IP ‘${current_ip}’, old IP ‘${registered_ip}'» >> /var/log/messages
else
echo «$(date +»%b %_d %T») $(hostname) $0: ERROR IP address could not be updated on freedns.afraid.org: current IP ‘${current_ip}’, registered IP ‘${registered_i$
fi
fi
Also it isn’t writing anything to /var/log/messages when i check that file.
Anybody know what i’m doing wrong?
Thank You
Daniel
Ah, I’ve seen this once. It was debugged down an issue with the OS itself. As it was only once, we suspected something specific to that box.
If there are more reports, then there’s more to it.
For general reference, the ticket in this case is #36411, also using Alma Linux 8.
We narrowed it down to this bug:
and it creeps into the dump of the direct_crons=1 (which everyone uses), where the data/users/fred/crontab.conf is filled based on `crontab -u fred -l`, but only seems to show up when a specific variation of the ENV is used, so duplicating it from the shell was unsuccessful.
I believe it’s related to this file:
Where the ENV DA is using when the crontab.conf rewrite happens contains:
Code:
0: BASH_FUNC_which%%=() { ( alias
...
25: which_declare=declare -fIf you type:
in the shell, you’d see the similar thing:
Code:
BASH_FUNC_which%%=() { ( alias; eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "[email protected]" }where it seems to be some sort of dynamic function feature, all preceded by BASH_FUNC_… where something about it isn’t working correctly.
Now that there’s other reports, I’ve added a temporary workaround to just filter out any crontab output lines that start with «sh: «.
By temporary, I’ve set a date of June 2022 to remove the code, so AlmaLinux should have definitely sorted it out by then, as I really don’t like adding extra complexity to DA code for other bugs, but the DA filtering with at least suppress the issue for now.
Reports on the above URL state that updating the system again should resolve it, but does clarify exactly which steps were taken.
I can speculate that you’d need to:
- Update your system with yum, and confirm that the /etc/profile.d/which2.sh has changed.. assumingly to include the } on the same line.
- You might need to login to ssh fresh to get the latest ENV vars loaded and restart DA so it gets the new ENV.
- Worst case, reboot the box to purge all instances of the bad ENV.
In any case, I’ve completed the workaround in DA, the alpha binaries should be up after the daily run (we only do it once a day now).
So if you’d like the workaround/fitler, wait until tomorrow, switch to the alpha update channel in your Licenses/Updates page, and grab those binaries. The next time the crontab.conf is re-written (eg: try full ./build rewrite_confs), it should filter out that output.
The other reported workaround solution was to add:
to your /etc/bashrc, start a new shell (run «bash») and restart directadmin. The restart might not be required as the crontab call does trigger a fresh shell, but it’s plausible that the old ENV vars DA already has might need to be purged. I’m not sure what that affects though, so might be a bit of an agressive hack, in case something needs the «which» function/alias they’ve setup.
Hopefully this gets everyone affected moving in the right direction. The main solution is to update the box with yum to get a proper fix.. and then flush the env.. likely with a fresh ssh login and DA restart. (reboot if required).
John