Выполнение чего-то в среде крона?

PS программ, вершина и smem все получают их данные из/proc. Возможно, Вы любили бы смотреть на исходный код для получения точных деталей. Те детали изменились за эти годы и вероятно продолжат изменяться.

smem программа является сценарием Python. Вот список полей в smem: http://selenic.com/repo/smem/file/43b299004079/smem#l271

Linux получает вершину и PS от пакета procps. Вот список полей в вершине: http://procps.cvs.sourceforge.net/viewvc/procps/procps/top.c?revision=1.134&view=markup#l1223

И вот список полей в PS: http://procps.cvs.sourceforge.net/viewvc/procps/procps/ps/output.c?revision=1.65&view=markup#l1286

1
07.03.2013, 22:53
2 ответа

Можно сделать это путем перенаправления STDERR к концу записи канала, затем закрытия конца чтения:

#!/usr/bin/env perl
pipe R,STDERR;
close R;
warn 'foo';
print "bar";
3
27.01.2020, 23:15

"Как эта функциональность работает?"

То, что Вы описываете, не является действительно функциональностью, это - дисфункциональность, вызванная неправильным представлением. Это не крон, который отправляет SIGPIPE, но это из-за способа, которым Вы используете его.

По электронным письмам крона по умолчанию stdout и stderr процесса владельцу crontab, использующего sendmail (см. man cron; если Вам не установили MTA, вывод просто отбрасывается), если они не перенаправляются. Чтобы сделать это, это должно ожидать процесса для завершения. Однако, если у Вас есть фон процесс с &:

* * * * * /bin/someprogram &

Это не будет ожидать, и если программа теперь попытается записать в stdout или stderr, то это получит SIGPIPE, потому что канал повреждается (конец чтения был закрыт). [Это могло бы также произойти с нефоновым процессом на более старых кронах, если Ваш MTA отсутствует, и у Вас есть большой вывод]

Таким образом, я собираюсь предположить, что у Вас есть что-то вроде этого в Вашем crontab:

* * * * * /bin/someprogram > log.file &

Значение stdout перенаправляется в файл, но канал stderr все еще повреждается. Это привело Вас к ошибочному заключению, что "крон выполняет любую программу, отправляется в него таким способом что что-либо записанное в причины STDERR... SIGPIPE".

Можно зафиксировать crontab любым удалением фоновой обработки & или перенаправление stderr также:

* * * * * /bin/someprogram 1>&2&> log.file &

Если Вы хотите. WRT, копирующий это самостоятельно, как qqx, говорит, просто закройте один конец канала и затем запишите в него.

3
27.01.2020, 23:15
  • 1
    я не имею & в моем crontab я называю сценарий оболочки, перенаправляющий stderr к stdout 2>&1. Тот сценарий оболочки запускает сценарий Perl без перенаправлений вообще. Что тот сценарий жемчуга выдает предупреждение, он умирает с 255. –  Evan Carroll 07.03.2013, 23:15
  • 2
    @EvanCarrol: Достаточно ярмарка, таким образом, это - или проблема sendmail или отношения между сценарием оболочки и сценарием жемчуга. Вы не отправили или тех вещей или crontab, таким образом, я не могу сказать. Однако в любом случае случай SIGPIPE случаен - это не то, как крон предназначается для функционирования. вышеупомянутое –  goldilocks 07.03.2013, 23:20
  • 3
    ничего не сделало, оно хорошо работало. Я просто не могу, почему независимо от того, что я делаю, не работает в Кроне. –  Evan Carroll 07.03.2013, 23:26
  • 4
    Пока Вы знаете, что это - знак, что-то не правильно. Если Вы хотите диагностировать проблему далее, необходимо задать другой вопрос и/или отправить часть включенного материала. –  goldilocks 07.03.2013, 23:33
  • 5
    В моем системном журнале это говорит, (КРОН) информация (Никакой MTA установленный, отбрасывающий вывод), интересно, означает ли это, что крон бросает SIGPIPE каждый раз, когда или STDERR или STDOUT не перенаправляются, и что-то появляется на тех потоках.. –  Evan Carroll 08.03.2013, 00:04

Теги

Похожие вопросы