Problema de script do serviço Yocto linux

Question

Eu escrevi um script systemd mqtt.service , que está no diretório /home/root

Este é o meu script mqtt.service :

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
[Unit]
Description=mqtt

DefaultDependencies=no
After=xdk-daemon.service


[Service]

Restart=always
RestartSec=10
ExecStart=/bin/sh /home/root/mosquitto-1.4/mqtt_start.sh



[Install]

WantedBy=multi-user.target

E este é o conteúdo de mqtt_start.sh

#!/bin/sh
/home/root/mosquitto-1.4/src/mosquitto -c /home/root/mosquitto-1.4/mosquitto.conf -d -p 1885 > /dev/null 2>&1

Se eu colar a linha:

/home/root/mosquitto-1.4/src/mosquitto -c /home/root/mosquitto-1.4/mosquitto.conf -d -p 1885

no terminal, o intermediário mqtt inicia normalmente Mas aqui eu não sou capaz de iniciá-lo

eu fiz

$ systemctl enable /home/root/mqtt.service
$ systemctl status mqtt.service
● mqtt.service - mqtt
   Loaded: loaded (/home/root/mqtt.service; enabled)
   Active: failed (Result: resources) since Mon 2015-04-06 10:42:48 UTC; 24s ago
 Main PID: 677 (code=exited, status=0/SUCCESS)

Apr 06 10:42:39 edison sh[677]: 1428316959: Warning: Mosquitto should not be run as root/administrator.
Apr 06 10:42:48 edison systemd[1]: mqtt.service holdoff time over, scheduling restart.
Apr 06 10:42:48 edison systemd[1]: mqtt.service failed to schedule restart job: Unit mqtt.service failed to load: No such file or directory.
Apr 06 10:42:48 edison systemd[1]: Unit mqtt.service entered failed state.

Deixe-me saber onde me confundi.

EDIT :

depois que eu reiniciei, fiz:

systemctl status mqtt.service e resultado:

● mqtt.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

    

Answer 1

Sua unidade de serviço do systemd é padronizada como Type=simple , mas seu script de wrapper está usando a opção --daemon . Essa é uma incompatibilidade de protocolo de prontidão. As incompatibilidades do protocolo de prontidão fazem com que os serviços não sejam iniciados corretamente ou (mais comumente) sejam (mal) diagnosticados pelo systemd como defeituosos.

O último está acontecendo aqui. Porque você tem overengineered seu sistema, seu daemon é desnecessariamente bifurcando duas vezes sobre , e o processo errado é o processo de daemon real. Além disso, você está duplicando desnecessariamente a funcionalidade da unidade de serviço do systemd em seu script de wrapper.

Livre-se do script de shell do wrapper e escreva sua unidade de serviço assim:

[Unit]
Description=Mosquitto MQTT Broker
Documentation=man:mosquitto(8)
Documentation=man:mosquitto.conf(5)
ConditionPathExists=/home/root/mosquitto-1.4/mosquitto.conf
After=xdk-daemon.service

[Service]
ExecStart=/home/root/mosquitto-1.4/src/mosquitto -p 1885 -c /home/root/mosquitto-1.4/mosquitto.conf
ExecReload=/bin/kill -HUP $MAINPID
User=mosquitto
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Observe que:

• Você não precisa da opção --daemon . O broker já é daemonized quando o systemd o executa.
• Você não deve usar a opção --daemon . O Mosquitto não fala o protocolo forking readiness, já que ele não está realmente pronto após o fork-and-exit. (Vivemos na esperança de que as pessoas um dia escrevam programas como esse, de modo que possam herdar seus soquetes de escuta e, portanto, sejam ativáveis por soquete).
• Você não precisa mexer na saída e no erro padrão em um script de wrapper. O systemd irá lidar com a saída padrão e erro do daemon. Eles são configuráveis no arquivo da unidade de serviço, se realmente necessário, mas isso não parece necessário para este programa.
• Como o processo correto, identificável pelo systemd, agora é o processo do daemon, systemctl reload mqtt.service agora pode enviar um sinal para o lugar certo e trabalhar.
• o próprio systemd chamará o intermediário como usuário mosquitto ; Portanto, você precisa ter certeza de que existe uma conta de usuário com esse nome, com os direitos de acesso necessários. Observe o aviso no seu log.
• O pessoal do systemd recomenda on-failure como a política de reinicialização acima de always .
• Não se deve definir DefaultDependencies como falso, a menos que o daemon de alguém seja realmente capaz de rodar muito cedo no processo de inicialização e no final do processo de desligamento, o que geralmente não é o caso da maioria das coisas. As dependências da unidade de serviço padrão são apropriadas para este tipo de daemon.