emerge install package с флагом, которого нет в ruby_targets
Нет. SIGHUP, вероятно, означает не то, что вы думаете.
В старые времена (а я говорю о 1970-х годах) терминал был устройством, которое подключалось к машине UNIX по последовательной линии. Часто это делалось через модемное соединение, поскольку в те времена приобретение второй машины было гораздо дороже, чем оплата телефонной связи; а используя модемную линию, вы могли делить машину с кем-то, находящимся далеко.
Когда вы заканчивали работу с машиной, необходимо было убедиться, что все, что вы запускали, будет остановлено, так как в те времена машины не имели такого количества ресурсов, как сегодня, и поэтому система помогала вам убедиться, что вы не забыли это сделать, посылая сигнал всем процессам, подключенным к вашей последовательной линии, когда модем зависал. Это был сигнал "зависания", название которого сократилось до SIGHUP.
В какой-то момент кто-то догадался, что иногда имеет смысл заставить процесс выполняться непрерывно, чтобы обеспечить определенный сервис для пользователей машины. Для того чтобы процесс действительно продолжал работать, его нужно было отсоединить от терминала, на котором он был запущен, чтобы при отключении пользователя и зависании модема процесс не был убит. Кроме того, если процесс не отсоединится от последовательной линии, то терминал не будет освобожден, и следующий пользователь, который попытается его использовать, не сможет этого сделать. Поэтому по этим причинам вы отсоединяетесь.
Теперь у вас есть давно запущенный процесс, который в какой-то момент может потребоваться перенастроить. Вы можете перезапустить его или заставить процесс время от времени опрашивать свой конфигурационный файл. Однако и то, и другое приводит к пустой трате ресурсов. Было бы гораздо лучше, если бы вы могли указать процессу, когда ему следует перечитать свой конфигурационный файл. Поскольку есть один сигнал, который для демона все равно не имеет смысла, почему бы просто не использовать его повторно? Верно, так и произошло, и в результате сегодня действительно принято, чтобы демоны перечитывали свой конфигурационный файл, когда они получают SIGHUP.
Но это только соглашение, и оно ни в коем случае не является общим правилом. Основная и документированная цель SIGHUP - сигнализировать о том, что терминальное соединение было разорвано. По этой причине действием по умолчанию для любой программы при получении сигнала SIGHUP по-прежнему является завершение работы, даже если процесс является демоном.
Таким образом, реализация init не может просто посылать SIGHUP случайным процессам, которыми она управляет. Да, во многих случаях действие перезагрузки действительно заканчивается отправкой SIGHUP демону через любую конфигурацию системы init (будь то скрипты init, файлы модулей systemd, конфигурация upstart или что-либо еще); но неверно предполагать, что так будет происходить всегда, и поэтому неверно говорить, что эти два действия эквивалентны.
Иногда это также объясняет, почему отправка SIGHUP на sshd в команде терминала убивает сессию; это потому, что sshd предполагает, что что-то убило соединение, и поэтому оно должно прерваться.