Что действительно подразумевает “под Debian на ходу для доказательства источников двоичных файлов”?

Я сам вмешался в эту проблему и решил сделать несколько тестов. Я полностью согласен с ответом, что следует упаковывать по каждому дистрибутиву отдельно, но иногда возникают практические вопросы, которые препятствуют этому (не в последнюю очередь трудовые ресурсы).

Таким образом, для тех, кто хочет «автообнаружить» вот что я узнал на ограниченном наборе дистро (подробнее ниже):

• Вы можете сказать выскочить из:

    [['/sbin/init --version '= ~ upstart]] & & эхо да | | эхо нет
  

• Вы можете сообщить systemd из:

    [['systemctl' = ~ -\.mount]] & & эхо да | | эхо нет
  

• Вы можете сообщить sys-v init из:

    [[-f/etc/init.d/cron & &! -h/etc/init.d/cron]] & & echo yes
  

Вот мои эксперименты со следующей командной строкой:

if [[ `/sbin/init --version` =~ upstart ]]; then echo using upstart;
elif [[ `systemctl` =~ -\.mount ]]; then echo using systemd;
elif [[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]]; then echo using sysv-init;
else echo cannot tell; fi

на ec2 экземплярах (я включаю идентификатор us-east AMI id):

• ArchLinux: использование systemd (с 2012,10,06 )
• CentOS6.4 ami-52009e3b: использование upstart
• CentOS7 ami-96a818fe: использование systemd
• Debian 6 ami-80e915e9: использование sysv-init
• Debian 7,5 ami-2c886c44: использование sysv-init
• Debian 7,6 GCE container-vm: использование sysv-init
• RHEL 6,5 ami-8d756fe4: использование upstart
• SLES 11 ami-e8084981: использование sysv-init
• Ubuntu 10,04 ami-6b350a02: использование upstart
• Ubuntu 12,04 ami-b08b6cd8: использование upstart
• Ubuntu 14,04 ami-a427efcc: использование upstart
• Ubuntu 14,10 и моложе: использование systemd
• AWS linux 2014,3,2 ami-7c807d14: использование upstart
• Fedora 19 ami-f525389c: использование systemd
• Fedora 20 ami-21362b48: использование systemd

Просто для ясности: Я не утверждаю, что это глупо! , почти наверняка нет. Также обратите внимание, что для удобства я использую матчи bash regexp, которые доступны не везде. Выше достаточно хорошо для меня сейчас. Тем не менее, если вы найдете дистрибутив, где он не работает, пожалуйста, дайте мне знать, и я постараюсь исправить его, если есть EC2 AMI, который воспроизводит проблему...

-121--4002-

Приближаясь к нему в другой путь "круглый: крон ведет журнал того, что он делает, именно для того, чтобы избежать такого рода проблем в первую очередь. В моей системе журнал хранится в /var/cron/log и выглядит следующим образом:

==> /var/cron/log <==
Oct 25 00:21:01 fortress cron[20232]: (vucar) CMD (/home/vucar/lighttpd-watchdog)

Эта строка сообщает мне, что экземпляр cron с PID 20232 на машине fortress выполняет /home/vucar/lighttpd-watchdog от имени пользователя vucar . Хорошо работающая система имеет только один cron, так что это будет просто.

Это также работает для на рабочих местах, так как они обычно просто передаются крону в любом случае:

==> /var/cron/log <==
Oct 25 00:28:01 fortress cron[31282]: (vucar) ATJOB (1414189680.c)

Фрагменты из системы BSD, но общая концепция, скорее всего, та же самая везде.

-121--25379-

Я исследовал источник того, как cron обрабатывает выходные данные своих заданий по почте:

• cron (8) устанавливает stdout и stderr выполняемого задания и направляет их непосредственно в mail (1) , не оставляя никаких временных файлов. См. do _ command.c вокруг линии 411 ( 1 ).
• Почта (1) должна быть полностью готова, так как ей нужны заголовки. Он открывает временный файл (обычно /tmp/mail-R... ), но удаляет его сразу, так как не оставляет следов. Loøk в коллекции.c на строке 83 ( 2 ).

В любом случае, как представляется, предпринимаются преднамеренные усилия не для того, чтобы оставить взаимопереплетающийся временный файл вокруг. Если вам нужно (или нужно) перехватить то, что происходит в длинном cronjob, вы должны настроить временный файл самостоятельно.

На этот момент я предлагаю, например, добавить tee $ HOME/cronjob.out в ваш cronjob, который захватывает копию результатов работы в безопасном месте.