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

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

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

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

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

Исправление Требуется перенаправлять вывод при запуске утилиты. При этом требуется выводить код возврата, если потребуется выяснить причины, то уже будет понятно, что надо смотреть в лог.

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

#!/bin/bash
. /cfg/config
. /etc/rc.d/init.d/functions
. /usr/local/Reductor/etc/const
 
prog="reductor"
 
start(){
	local RC
	echo -n $"Starting $prog: "
	/usr/local/Reductor/bin/start.sh &>> $LOGFILE
	RC=$?
	if [ $RC != 0 ];then
		echo -e "\nПри остановке редуктора произошли ошибки."
		echo "Выяснить причины можно в $LOGFILE"
	fi
	return $RC
}
 
...

~~OWNERAPPROVE~~

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

Yes:
, Nikolay Carbonsoft,

No:

Обсуждение

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 например.
Ваш комментарий. Вики-синтаксис разрешён: