Вопрос уважаемым знатокам: BASH и SIGHUP

nohup?

Опа, точно! А я раньше как-то не задумывался над названием этой утилиты :) Спасибо вам огромное!

Зря я обрадовался, не помогает :(
То есть процесс rsync всё равно получает свой сигнал
При этом он, зараза, умирает даже от SIGUSR1! Вот какому... пришло в голову таким образом обрабатывать SIGUSR1 и зачем это было нужно? :(

Возмозжно, это из-за того, что я на самом деле использую eval «nohup rsync bla bla &>rsync.log &», но вряд ли

man bash /SIGNALS

Мда, в итоге вообще ничего и не должно работать, судя по man bash'у. Печально... Разве только цикл ожидания какой замутить

Я сделал так:

 #!/bin/bash

hndlSIGHUP () { log_ 'Received SIGHUP, what do i have to do now?' return 0 } trap hndlSIGHUP SIGHUP eval "nohup ./run_forever" pid=$! wait $pid (( $? )) && \ log_ 'Oh, shit, WTH happens with rsync?!'

130 aaqeq ~ $ pidof run_forever
aaqeq ~ $ ./nohup.sh &
[1] 23599 
aaqeq ~ $ pidof run_forever
 23601 
aaqeq ~ $ kill -1 23599
aaqeq ~ $ pidof run_forever
23601 
aaqeq ~ $ pkill 23599 
1 aaqeq ~ $ kill -9 23599 
[1]+ killed ./nohup.sh 
aaqeq ~ $ pidof run_forever
23601
aaqeq ~ $ kill -9 23601
aaqeq ~ $
 

Работает.

см. disown в bash

В Вашем примере до pid=$! никогда не дойдёт, потому что nohup не отправляет команду в background, так что пока она не выполнится (а она этого, судя по названию, никогда и не сделает), управление последующие команды не получат. И как вы проверили то, что отрабатывает hndlSIGHUP?

НО! Сигнал почему-то получает не только собственно мой скрипт, но и форкнутый им процесс rsync!

Тогда я не понял условие задачи.

Во время работы отправляю данному скрипту сигнал HUP.

Если я посылаю HUP скрипту, то run_forever не завершается. run_forever из-за того, что я не догадался запустить что-то ещё. Или не это нужно было?

Ничего не понял. «got beyond nohup once» и «got beyond nohup twice» вы увидите в данном случае по-любому. Вопрос в том, что при получении HUP завершается wait и рассылается HUP порождённым процессам. Что доказывает приведённый вами пример в данном контексте? Кстати, то, что rsync завершается при получении HUP - нормальной штатное поведение (а то, что его не обрабатывает run_forever - не штатное). Вопрос только в том, что хотелось бы перехватывать этот сигнал trap'ом полностью, в т.ч. и по отношению к порождённым процессам.

Обработчики сигналов не могут наследоваться по самой своей природе.
A чтобы не слетал rsync его следует запускать так:

 { trap '' HUP ; rsync .... ; } & 

Слушайте, а ведь вы наверное правы (только скобки круглые, а не фигурные скорее всего)! Спасибо, попробую, доложусь.
Но там есть ещё одна проблема: я использую wait, а если я правильно понимаю man bash, то при получении сигнала и срабатывании обработчика - wait завершится с 128+X, где X-номер сигнала. Собственно, именно это я и наблюдаю: при отправке сигнала HUP wait завершается с кодом 129, при отправке сигнала WINCH - с кодом 156.

If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. When bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return immediately with an exit status greater than 128, immediately after which the trap is executed.

Ну да, давно я с распараллеливанием на bash не возился, подзабыл.
Тогда, видимо, нужно wait зациклить, пока не вернет что либо отличное от
128+<требуемый сигнал>.