Existe uma maneira de fazer o systemctl iniciar síncrono

1

Estou desenvolvendo / desenvolvi um arquivo de unidade para systemd

[Unit]
Description=FreeRADIUS multi-protocol policy server
After=syslog.target network.target
Documentation=man:radiusd(8) man:radiusd.conf(5) http://wiki.freeradius.org/ http://networkradius.com/doc/

[Service]
EnvironmentFile=-/etc/sysconfig/radiusd
ExecStartPre=/usr/sbin/radiusd $FREERADIUS_OPTIONS -Cxm -lstdout
ExecStart=/usr/sbin/radiusd $FREERADIUS_OPTIONS -fm
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

Vivenciando um problema em que chamar systemctl radiusd start não retorna um código de erro, mesmo se /usr/sbin/radiusd -fm sair com um.

Existe uma maneira de fazer o systemctl agir de forma síncrona? isto é, esperar por um período definido antes de retornar e indicar que o serviço foi iniciado com sucesso / sem sucesso.

Eu estou bem em mudar para Type=forking ou qualquer uma das outras opções, como dbus (e escrever o código para integrar com dbus) se isso significa systemctl sairá com um erro indicando que o serviço falhou ao iniciar. / p>

Para antecipar-se à pergunta óbvia, sim, depois do início, o systemd vê a unidade como falhada.

bash-4.2# systemctl status radiusd
radiusd.service - FreeRADIUS multi-protocol policy server
   Loaded: loaded (/usr/lib/systemd/system/radiusd.service; enabled)
   Active: failed (Result: start-limit) since Wed 2015-08-12 12:26:18 EDT; 19s ago
     Docs: man:radiusd(8)
           man:radiusd.conf(5)
           http://wiki.freeradius.org/
           http://networkradius.com/doc/
  Process: 10610 ExecStart=/usr/sbin/radiusd $FREERADIUS_OPTIONS -fm (code=exited, status=1/FAILURE)
 Main PID: 10610 (code=exited, status=1/FAILURE)

e sim systemctl status radiusd retorna um código de saída não 0. Apenas irritante para integrar isso com a pilha de sal. Atualmente, sem o início síncrono, o módulo pkg de pilha de sal dentro do pacote relata o serviço como em execução, depois de aplicar atualizações de configuração / código que causam falhas no serviço.

    
por Arran Cudbard-Bell 12.08.2015 / 18:55

1 resposta

2

Eu acho que você já respondeu sua própria pergunta.

Se você quiser separar um daemon e desejar que o systemctl retorne o código de status, Type=forking é o caminho a ser seguido. Há Type=oneshot também. Você deve usar isto somente quando você espera que seu script / programa saia, ao invés de executar como daemon. O systemctl, na verdade, aguarda o término do programa ExecStart= .

Da minha máquina CentOS 7.1:

[unixguy@infra01 system]$ pwd
/usr/lib/systemd/system
[unixguy@infra01 system]$ find ./ -type f | xargs grep 'Type='  | awk -F: '{print $2}' | sort | uniq -c | sort -nr | head -5
     64 Type=oneshot
     37 Type=forking
     11 Type=notify
      6 Type=idle
      6 Type=dbus
[unixguy@infra01 system]$ find ./ -type f | xargs grep 'Type=forking' | awk -F: '{print $1}' | head
./rc-local.service
./rdisc.service
./tcsd.service
./plymouth-kexec.service
./plymouth-halt.service
./plymouth-poweroff.service
./plymouth-reboot.service
./plymouth-start.service
./rpc-statd.service
./systemd-cfengine-bootstrap.service
[unixguy@infra01 system]$ find ./ -type f | xargs grep 'Type=oneshot' | awk -F: '{print $1}' | head
./systemd-kexec.service
./quotaon.service
./halt-local.service
./initrd-cleanup.service
./initrd-parse-etc.service
./initrd-switch-root.service
./initrd-udevadm-cleanup-db.service
./kmod-static-nodes.service
./systemd-binfmt.service
./[email protected]

Como você pode ver, os serviços de daemon estão usando Type=forking e serviços / scripts de execução únicos estão usando Type=oneshot

    
por 12.08.2015 / 19:52