как отследить проблемы с запуском в cron

Можно обновиться до systemd.
Можно завернуть выхлоп в отдельный лог:

cmd >logfile 2>&1

cmd >logfile 2>&1

скрипт лежит в /etc/cron.monthly, неужели делать ещё один скрипт, который будет запускать нужный? как всё это дело тестировать? ждать месяцами не очень хочется.

Добавьте перенаправление прямо к команде в кронтабе.

нет команды в кронтабе, скрипт просто лежит в /etc/cron.monthly

ok, спасибо, костыли костылями, непонятно как тестировать только

костыли костылями

Отладка cron, как она есть.

непонятно как тестировать только

http://stackoverflow.com/questions/4984725/how-to-test-cron-job
http://stackoverflow.com/questions/4883069/debugging-crontab-jobs

А выделить в конфиге сислога кроновый лог в отдельный файл религия не позволяет?

destination d_cron { file("/var/log/crond.log"); };
filter f_cron { facility(cron); };
log { source(src); filter(f_cron); destination(d_cron); };

Еще настроить rotate, потом всё это еще автоматизировать, и ждать месяцами когдаж мой скрипт выполнится, удобно ничего не скажешь... И кто только системд придумал лишив нас такого удовольствия...

ни разу не слышал претензии к функционалу системд, только к архитектуре и идеологии

соседняя тема: Как в systemd добавить скрипт, который является демоном?

так там же не претензия, там неосилятор, где аргументы?

Вангую традиционное отсутствие ожидаемых переменных окружения в запускаемых кроном скриптах.

ни разу не слышал претензии к функционалу системд, только к архитектуре и идеологии

Вот именно, что претензии к функционалу, жаловались на таймеры, типа нафига есть крон, жаловались на journald, есть же syslog и греп, в моём случае на машине с systemd настройка и отладка заняла минуты, удобно и быстро, а с кроном и тестовыми логами, уже второй месяц не работает.

Двачую таймеры, после них на убогий cron без слёз не взглянешь.

http://suckless.org/sucks/systemd
вот претензии по существу, если бы авторы ещё и запилили функциональный аналог, нормальный, было бы вообще круто.

Там преимущественно 4.2.

там преимущественно недовольство что система инита делает всё на свете, вместо заранее определенного круга задач.

вместо заранее определенного круга задач

Проект растёт, развивается, эволюционирует.
Соответственно актуальным потребностям меняется и круг задач.
Это нормально.

[/usr]/bin/systemd делает только то, что действительно имело смысл запихнуть в PID1, всё остальное отдельно. И не система инициализации, а эффективныйсистемный менеджер.

с cron и syslog, логи свалка, так как сервер боевой и пишет достаточно много туда, к моменту как заметишь проблему, логи уже потёрлись

Так настрой syslogd, чтобы интересующие тебя логи направлялись в отдельные файлы. С syslog-ng это очень легко делается, он даже в базу может писать если надо

Так настрой syslogd, чтобы интересующие тебя логи направлялись в отдельные файлы.

простой редирект логов не проблема, только за ним всплывает ротация логов, автоматизация всего этого в configuration manager, и месяцы отладки, я прекрасно это понимаю, уже настроил и сделал, вроде должно работать, скрипт поправил, теперь жду пару месяцев чтоб проверить, вот только заняло у меня это раз 20 больше времени, чем то же самое для сервера systemd/timer/journald.

Настройка logrotate тоже не требует каких-то особых усилий, а если скрипт «под отладкой» и пишет в лог три строчки в месяц то его вообще не надо ротировать

вот претензии по существу,

какое по существу?

systemd does {,U}EFI bootload

нет, этим занимается systemd-boot, хочешь пользуй любой другой бутлоадер, я пользовался gummiboot до того как он стал systemd-boot, мне нравится его лёгкость и простота

Being journal files binaries written with easily corruptable transactions

ну были у меня повреждения, и что? ну не читается эта часть лога как она не читалась бы и в текстовом формате, зато удобство выборки по времени, буту, сервису и 2 миллионам других вещей побеждает танцы с грепом.

systemd now does your DNS

нет не does, если и занимается этим, то не systemd, а systemd-resolved, у меня dnscrypt-proxy + dnsmasq, опять же сетью заведует NetworkManager на ноуте, а не systemd-networkd, а вот на файлопомойке systemd-networkd, ибо функционала хватает, простота настройки нравится, работает стабильно.

остальное лень разбирать.

И вообще нехер мешать всё в кучу, никто не заставляет пользоваться утилитами systemd-что-то там, используй свои любимые крон,ntpdate итд.

если бы авторы ещё и запилили функциональный аналог,

аналог чему? авторы пилят что им нравится, они запилили аналог resolveconf, ntp, grub, и куче других вещей, они иногда проще и менее функциональны, но кому-то их хватает и они нравятся, если мне нужно только время на компе синхронизить, мне не нужен ntpdate, systemd-timesyncd делает эту работу замечательно, нужно время раздовать, вот тут сорри, ntpdate побеждает, а если тебя не устраивает возьми и запили аналог сам.

Настройка logrotate тоже не требует каких-то особых усилий, а если скрипт «под отладкой» и пишет в лог три строчки в месяц то его вообще не надо ротировать

Таких «пидерасов», которым не надо ротировать, надо пальцы отрубать, потому что в 3 ночи упавшие сервера поднимать мне, а они видите ли забыли про «отладку»....