I have written a systemd script
mqtt.service which is in
This is my
mqtt.service script :
# 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
And this is the content of
#!/bin/sh /home/root/mosquitto-1.4/src/mosquitto -c /home/root/mosquitto-1.4/mosquitto.conf -d -p 1885 > /dev/null 2>&1
If I paste the line :
/home/root/mosquitto-1.4/src/mosquitto -c /home/root/mosquitto-1.4/mosquitto.conf -d -p 1885
into terminal, the mqtt broker starts normally
But here I am not able to start it
$ 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: 1428316959: Warning: Mosquitto should not be run as root/administrator. Apr 06 10:42:48 edison systemd: mqtt.service holdoff time over, scheduling restart. Apr 06 10:42:48 edison systemd: 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: Unit mqtt.service entered failed state.
Let me know where I have mistaken.
after I reboot I did:
systemctl status mqtt.service and result :
● mqtt.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Your systemd service unit is defaulting to
Type=simple but your wrapper script is using the
--daemon option. That is a readiness protocol mismatch. Readiness protocol mismatches cause services not to start correctly, or (more usually) to be (mis-)diagnosed by systemd as failing.
The latter is happening here. Because you’ve overengineered your system, your dæmon is unnecessarily forking twice over, and the wrong process is the actual dæmon process. Also, you are needlessly duplicating systemd service unit functionality in your wrapper script.
Get rid of the wrapper shell script entirely, and write your service unit like this:
[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
- You do not need the
--daemonoption. The broker is already daemonized when systemd runs it.
- You should not use the
--daemonoption. Mosquitto does not speak the
forkingreadiness protocol, since it is not actually ready after the fork-and-exit. (We live in hope of people one day writing programs like this such that they can inherit their listening sockets and thus be socket-activatable.)
- You do not need to fiddle around with standard output and error in a wrapper script. systemd will handle a dæmon’s standard output and error. They are configurable in the service unit file if really necessary, but that does not seem necessary at all for this program.
- Since the correct process, identifiable by systemd, is now the dæmon process,
systemctl reload mqtt.servicecan now send a signal to the right place, and work.
- systemd itself will invoke the broker as user
mosquitto; so you need to make sure that a user account by that name exists, with the requisite access rights. Notice the warning in your log.
- The systemd folk recommend
on-failureas the restart policy over
- One should not set
DefaultDependenciesto false unless one’s dæmon is actually capable of running very early in the boot process and late in the shutdown process, which is usually not the case for most things. The default service unit dependencies are appropriate for this sort of dæmon.