bg

screen

а давай так: скрипты должны быть запущены не только человеком из консоли, но и джобом в дженкинсе, например. или еще каким-то средством автоматизации.

Примерно так выглядит твой вопрос:

Вот и вопрос - как правильно запускать скрипты в качестве демона в фоне? (без всяких systemd unit и rc.init)

Вот и вопрос - как правильно забивать гвозди? (без всяких молотков и гвоздозабивных пистолетов).

Коллега утверждает, что использовать nohup нельзя, потому что это отсекает возможность использовать kill -HUP, но я не видел, чтобы он хоть раз этим пользовался.

Кстати, я не уверен, что это в действительности так. Если приложение, запущенное под nohup, установит собственный обработчик SIGHUP, то по kill -HUP он должен срабатывать. А если не установит, то kill -HUP не будет иметь практического смысла.

что это вообще за SIGHUP и зачем он?

setsid [...] &

кстати screen для этого отлично подходит - можно при желании еще и заглянуть в консоль, что там автоматизированно так выполняется.

а давай.

&

screen -Sdm

Дебилов полон тред.

Вот и вопрос - как правильно запускать скрипты в качестве демона в фоне? (без всяких systemd unit и rc.init)

``` fork(); fork(); ``

Вот и вопрос - как правильно запускать скрипты в качестве демона в фоне? (без всяких systemd unit и rc.init)

fork();
fork();

Вот и вопрос - как правильно запускать скрипты в качестве демона в фоне? (без всяких systemd unit и rc.init)

Вот и вопрос - как правильно забивать гвозди? (без всяких молотков и гвоздозабивных пистолетов)

+1

И если на то пошло, то не nohup, а setsid. Тебя же интересует, чтобы он не умирал при закрытии терминала, а не что-то ещё?

да, но тут поголовно все советуют screen и nohup

Миллионы мух.

Вообще читать сюда — вот так правильно. Ну и смотри, что каждая конкретная тулза делает или не делает.

ок. я понимаю, что меня закидают тапками, но мне бы «просто запустить в фоне java-процесс» :)

systemd-run java ...

RedHat Enterprise Linux 6.4 без systemd и не всегда есть доступ до рута

Тогда только страдать попробуй daemonize(1): http://software.clapper.org/daemonize/

cmd & disown

что это вообще за SIGHUP и зачем он?

Процесс получает этот сигнал когда прекращает свою работу терминал в которым был запущен процесс, процесс должен сам себя корректно завершить, системные процессы (демоны) используют этот сигнал по другому, там обычно им обозначают что нужно перечитать конфиг, т.е. например обновил конфиг nginx и передал sighup одноименному процессу.

использовать nohup нельзя, потому что это отсекает возможность использовать kill -HUP

Это тот же сигнал что посылает закрывающийся терминал, только тут его явно посылает пользователь, разницы нет.

Ты путаешь тёплое с мягким. Демонам не нужен nohup. nohup не делает процесс демоном. Это несвязанные вещи. Почитай Стивенса «Advanced programming in Unix Environment»

не только человеком из консоли, но и джобом в дженкинсе

Прям даже и стесняюсь спросить как-то... а чем отличается запуск скрипта человеком от запуска скрипта дженкинсом, пусть даже из пайплайна на слейв?

Для запуска скрипта в фоне нужно использовать & в конце строки.

Режимом работы интерпретатора. При запуске в консоли активируется дополнительная функциональность по управлению фоновыми задачами.

nohup ./script & 

чем не устраивает?

меня-то всем устраивает. моего коллегу не устраивает.

что это вообще за SIGHUP и зачем он?

Многие «традиционные» демоны используют SIGHUP для переначитки конфигов. Если твой процесс не имеет специальной обработки SIGHUP, то пользуйся и не парься

нельзя, потому что это отсекает возможность использовать kill -HUP

В треде знатоки, шо пипец.

nohup включает игнорирование сигнала, который по дефолту, если не было такого включения игнорирования — убивает процесс. Если ваш демон умеет сам реагировать на SIGHUP, он поставит обработчик этого сигнала и запуск этого демона с nohup ничего не поменяет, кроме того, что это будет просто избыточно-бесполезно.

у меня в скрипте запускается java -jar ... не знаю, как оно с этим сигналом дружит

Во-первых, можно же и проверить, во-вторых, судя по всему у вас скрипт, а не демон, и nohup тут еще и подготавливает stdin/stdout для работы с фоном, так что скорее всего лучше с ним.

Это был тонкий намек, что screen использовать - не вариант, ибо дженкинс :)

Если ваш демон умеет сам реагировать на SIGHUP, он поставит обработчик этого сигнала и запуск этого демона с nohup ничего не поменяет, кроме того

…что этот обработчик не получит управление. Запусти

#!/bin/bash

trap "echo 'Bite me!'" HUP

echo $$
while true; do :; done

screen использовать - не вариант, ибо дженкинс :)

Из дженкинс нельзя запустить screen с нужной командой в нем?

вот честно - не знаю. но надо ж еще и перезапустить.

а как дженкинс убивает процесс с nohup?

kill-ом

screen -S screen_name -X quit

дженкинс так могёт, я проверял, когда у нас был дженкинс

ну это имхо извращение

моя твоя не понимать.

ты спросил как запускать если не с nohup. почему не nohup - ты ссылаешься на коллегу, который в отличие от тебя знает, что задающий вопросы всегда выглядит умнее отвечающего и просто заявил, что nohup - не кошер.

тебе дали пачку вариантов, жизнеспособность которых одинакова, а применимость и нужность зависит от задач, но все одинаково подходят и для интерактива и для ci/cd.

и ты такой: ну это имхо извращение. а быть омежкой и слушать ламера-коллегу - не извращение?

непосредственно и с nohup, и сравни результаты.

Это особенность sh-ов, hup тут ничем не отличается от других сигналов: если сигнал игнорируется, то trap не устанавливается. Обычные программы-демоны, устанавливают обработчики когда их об этом просят.

я не слушаю коллегу, я ищу правды и подтверждения/опровержения того, что мой вариант с nohup - правильный для моей ситуации.

так ты же сам говоришь, что его что-то не устраивает. наверное надо его спросить, не?

дык он аргументирует это только тем, что не будет обрабатываться сигнал hup, но ничего не говорит о том, что это вообще необходимо :)

ну это уже неадекват какой-то. попробуй его по_«и чё?»_кать.

я так и сделал :) но, засомневавшись, решил спросить тут, так что не серчай шибко

да я так, время есть. а неадеквата ты всё же прощупай.

Если ваш демон умеет сам реагировать на SIGHUP, он поставит обработчик этого сигнала и запуск этого демона с nohup ничего не поменяет, кроме того

…что этот обработчик не получит управление. Запусти <код на баше> непосредственно и с nohup, и сравни результаты.

Это особенность обработки сигналов, специфичная для bash (и возможно других совместимых шеллов), смотри в man bash описание trap:

Signals ignored upon entry to the shell cannot be trapped, reset or listed.

Если попробовать написать то же самое на другом ЯП (например на питоне), то результат будет другой:

import os
import signal
import sys


def handler(signum, frame):
    print ('Signal handler called with signal', signum)
    sys.stdout.flush()


# Set the signal handler and a 5-second alarm
signal.signal(signal.SIGHUP, handler)

print('PID:', os.getpid())
sys.stdout.flush()
while True:
    pass

SUGHUP отлично ловится что без nohup, что с ним.

Это особенность обработки сигналов, специфичная для bash

Можно было и не повторять одну и туже мысль, что я отвечал на заданный мне вопрос через час.