systemd service startup issue

Question

Это первый раз, когда я использовал systemd и немного не уверен в чем-то.

У меня есть сервис, который я создал (для GeoServer работает под котом):

[Unit] 
Description=Geoserver 
After=network.target 

[Service] 
Type=oneshot 
ExecStart=/usr/local/geoserver/bin/startup-optis.sh 
ExecStop=/usr/local/geoserver/bin/shutdown-optis.sh 
User=geoserver 

[Install] 
WantedBy=multi-user.target 

сценарий запуска делает Exec для запуска Java/Tomcat. Запуск службы из командной строки, кажется, работает:

sudo systemctl start geoserver 

Однако команда не возвращается, пока я Ctrl-C, это не кажется мне правильным. После этого процесс java продолжает работать и функционирует нормально. Я не хочу перезагружать окно, чтобы проверить это, если это вызовет проблемы во время init, и это удаленная машина, и было бы больно заставить кого-то обратиться к ней.

Answer 1

Вам нужно установить правильный «тип» в разделе «Сервис»:

[Service] 
... 
Type=simple 
... 

Тип

Настраивает процесс запуска типа для данного устройства службы. Один из простых, forking, onehot, dbus, уведомлять или простаивать.

Если установлен простой (по умолчанию, если ни Type = ни BusName =, но ExecStart = указаны), ожидается, что процесс настроен с ExecStart = является основным процессом службы. В этом режиме, если процесс предлагает функциональные возможности для других процессов в системе, его коммуникационные каналы должны быть установлены до запуска демона (например, сокеты, установленные системойd через активацию сокета), так как systemd немедленно продолжит работу начиная с последующих блоков.

Если установлено значение forking, ожидается, что процесс, сконфигурированный с помощью ExecStart =, вызовет fork() как часть его запуска. Ожидается, что процесс родителя завершится, когда пуск завершен и все каналы связи настроены. Ребенок продолжает работать как основной процесс демона . Это поведение традиционных демонов UNIX. Если этот параметр используется, рекомендуется также использовать параметр PIDFile = , чтобы systemd мог идентифицировать основной процесс демона. systemd продолжит запуск последующих блоков, как только выйдет родительский процесс .

Поведение одного выстрела похоже на простое; однако ожидается, что процесс должен выйти до того, как система начинает запускать контрольные единицы. RemainAfterExit = особенно полезен для этого типа обслуживания. Этот является подразумеваемым значением по умолчанию, если не указаны ни Type =, ни ExecStart =.

Поведение dbus аналогично простому; однако ожидается, что демона приобретает имя на шине D-Bus, как установлено BusName =. systemd продолжит запуск последующих блоков после того, как было получено имя шины D-Bus . Сервисные модули с этой опцией настроены неявно, чтобы получить зависимости от блока dbus.socket. Этот тип является значением по умолчанию, если задано BusName =.

Поведение оповещения аналогично простому; однако ожидается, что демон отправит уведомление через sd_notify (3) или эквивалентный вызов , когда он завершит запуск. systemd продолжит со стартовыми контрольными единицами после отправки этого уведомления . Если этот параметр используется, NotifyAccess = (см. Ниже) должен быть установлен , чтобы открыть доступ к сокету уведомлений, предоставленному systemd. Если NotifyAccess = не установлен, он будет неявно установлен на main. Обратите внимание, что в настоящее время Type = notify не работает, если используется в сочетании с PrivateNetwork = yes.

Поведение простоя очень похоже на простой; однако фактическое выполнение служебного двоичного кода задерживается до тех пор, пока не будут отправлены все задания. Этот может использоваться для предотвращения чередования вывода служб оболочки с выходом состояния на консоли.