2018-11-21 Перенаправление Всего Вывода В Утилитах

2018-11-21_перенаправление_всего_вывода_в_утилитах.1542803333.txt.gz | Хозяин: николай_глазов | Изменен: 20.05.2019 15:18 николай_глазов | Утвержден(николай_глазов 2018/11/21 07:29)
Новейший утвержденный

Это старая версия документа.

~~OWNERAPPROVE~~

Прочитал правила разработки как не надо делать 2018-11-21 перенаправление всего вывода в утилитах
Yes(2) No(0) Clear

Yes:
, Nikolay Carbonsoft,

No:

Что произошло: Нельзя полностью перенаправлять вывод утилит в лог. Это нарушение strongbash020.\\
Постановка задачи: Сделать вменяемый вывод /app/reductor/service restart .

Разбор: При рестарте редуктора(/app/reductor/service restart) выполняется много действий. Идёт запуск нескольких утилит. Вывод от них довольно большой, из-за этого теряется смысл запуска редуктора.\\
Ошибка: В нескольких утилитах, которые запускаются при инициализации было написано следующее:

#!/bin/bash\\
. /app/reductor/usr/local/Reductor/etc/const\\
exec 1>"$LOGFILE"\\
exec &>"$LOGFILE"

.....

Тем самым весь вывод от утилиты переводится в файл. Это затрудняет работу с утилитами, потому что при запуске из консоли не увидим вывода и ошибок при запуске.

Для исправления потребовалось из init - скрипта вывод утилит перенаправлять в лог.

/etc/rc.d/init.d/reductor 

#!/bin/bash\\
. /cfg/config\\
. /etc/rc.d/init.d/functions\\
. /usr/local/Reductor/etc/const

prog="reductor"\\
\\
start(){

echo -n $"Starting $prog: "\\
    /usr/local/Reductor/bin/start.sh\\
/usr/local/Reductor/bin/start.sh &>> $LOGFILE\\
}\\
\\
stop(){

echo -n $"Shutting down $prog: "\\
/usr/local/Reductor/bin/stop.sh\\
/usr/local/Reductor/bin/stop.sh &>> $LOGFILE\\
}

Обсуждение

Krat NikolayKrat Nikolay, 26.11.2018 05:34

Только это проблема не совсем strongbash020. Здесь нестыковка с unix-style, когда утилиты должны писать логи в stdout/stderr, а не в лог-файлы. Т.к. это приводит к проблемам сопровождения и отладки.

Также, в исправленном варианте полное перенаправление - достаточно опасная операция. Можно замаскировать возможные проблемы, а система должна открыто сообщать о своих проблемах. Здесь мы это допустили, т.к. в случае проблем код возврата будет не нулевой и мы увидим ERROR при запуске. Дополнительно решили добавить обработку ошибочного кода возврата и писать в вывод: «Лог проблемы можно посмотреть в $LOGFILE»

Krat NikolayKrat Nikolay, 26.11.2018 05:36

Причем это допустимо только при вызове pl7-скриптов, где мы можем полагаться на код возврата. Иногда, мы этого сделать не можем и параметры вывода могут «утечь» к низлежащим скриптам

adminadmin, 04.12.2018 07:09

по идее все есть в boot.log то что при старте

если нас рестартить апдейтер(по сути крон), то он и должен логировать либо использовать crab_exec с логированием

если мы делаем рестарт руками, то мы и так все видим

Стандартные выводы должны быть unix style

Олег СтрижеченкоОлег Стрижеченко, 11.12.2018 05:49
по идее все есть в boot.log то что при старте

Если сделать такое перенаправление - этого там не будет.

Только reductor start… [OK/FAIL]

adminadmin, 19.12.2018 04:29 (19.12.2018 04:30)
  • если ничего не перенаправлять, то все попадет в boot.log
  • если рестартить из консоли, то все попадет в консоль и все видно
  • если рестартить из апдейта или крона, то там и логировать /app/reductor/service restart &»updater.log
  • в самом скрипте логировать не надо в 99.9% случаев
  • если логирование все же понадобилось, для журналирования действий, то оно должно дублировать stdout, stderr, а не забирать себе. НО ЭТО В САМЫХ КРАЙНИХ НУЖНЫХ СЛУЧАЯХ, так делает vzctl например.
Ваш комментарий. Вики-синтаксис разрешён: