☰

Преобразование службы /etc/init.d в systemd

tag-icon • tag-icon linux services systemd init
Преобразование службы /etc/init.d в systemd

Я нахожусь в процессе преобразования существующей службы /etc/init.d в systemd. Казалось бы, это работает, но я столкнулся со странной проблемой. Служба systemd успешно запускается командой "systemctl start service_name" и останавливается командой "systemctl stop service_name", но, похоже, она не останавливается чисто. Базовое приложение проверяет, запущено ли оно уже, и немедленно завершает работу, если это так. Вот что происходит.

Вот эквивалентный фрагмент из старого скрипта /etc/init.d:

kill_process() {
    pkill -SIGINT service_name
    sleep 1
    if [ -n "$(pgrep service_name)" ]; then
        pkill -SIGTERM service_name
        sleep 1
    fi 
    if [ -n "$(pgrep service_name)" ]; then
        pkill -SIGKILL service_name
        sleep 1
    fi 
    if [ -z "$(pgrep service_name)" ]; then
        rm -f /var/lock/subsys/service_name
    fi
}

start() {
    action $"Starting Service: " /sbin/service_name
}

stop() {
    action $"Stopping Service: " kill_process
}

restart() {
    stop
    start
}

А это моя первая попытка эквивалента systemd:

[Unit]
Description=Service Name

[Service]
ExecStart=/sbin/service_name

[Install]
WantedBy=multi-user.target

Я понимал, что служба systemd будет обрабатывать завершение процесса с помощью SIGTERM, но я экспериментировал с другими значениями KillSignal и ExecStop. Однако мне еще предстоит понять эту разницу в поведении завершения. Более того, если я вручную завершаю приложение с помощью SIGINT, это также не завершает службу чисто. Мне интересно, делает ли /etc/init.d что-то еще за кулисами.

Будем признательны за любые предложения.

решение1

Я просто хотел подвести черту под этим постом на случай, если он будет интересен кому-то еще.

Приложение C, работающее как часть сервиса, ранее использовало fork(), если getppid() еще не был равен 1 (т. е. еще не был форкнут). Похоже, что когда приложение запускается systemd, у него уже есть родительский PID 1. Раньше у нашего приложения не было явной обработки SIGTERM, но оно корректно завершало работу при реакции на SIGINT в контексте /etc/init.d. Я добавил специальный обработчик SIGTERM, и теперь сервис ведет себя так, как и ожидалось.

Связанный контент