[Feature request]: Improve zigbee2mqtt startup experience by a better use of systemd unit definition

[IgnacioHR]

Is your feature request related to a problem? Please describe

Hi,

There are issues like #17032, #361, #17012 and #4829 to mention some that are related to the way the zigbbe2mqtt service unit is defined.

Current recommended unit definition is documented [here] (https://www.zigbee2mqtt.io/guide/installation/01_linux.html#optional-running-as-a-daemon-with-systemctl)

But there are multiple issues with this definition;

There is no Type= defined in the service. As stated in the documentation here the default value is set to simple and, as stated in the documentation "... this means systemctl start command lines for simple services will report success even if the service's binary cannot be invoked successfully".

Describe the solution you'd like

The documentation for systemd units recommends to use either exec or notify

Change to exec is straight forward. Just use this new unit definition:

[Unit]
Description=zigbee2mqtt
After=network.target

[Service]
Environment=NODE_ENV=production
Type=exec
ExecStart=/usr/bin/npm start
WorkingDirectory=/opt/zigbee2mqtt
StandardOutput=inherit
# Or use StandardOutput=null if you don't want Zigbee2MQTT messages filling syslog, for more options see systemd.exec(5)
StandardError=inherit
Restart=always
RestartSec=10s
User=pi

[Install]
WantedBy=multi-user.target

This solves some problems like missing the user or the executables defined in the unit. But it is still sub-optimal because the zigbee2mqtt service depends on the controller to be initialised properly. For example, if you are using a USB controller and you remove it from the computer the service will be considered started by the operating system but it is useless. So IMO the service should be called as Type=notify.

Implementing Type=notify requires the code to notify the service daemon when it has succesfully started. Hopefully there is a library here that can be used for this purpose inside node.

Describe alternatives you've considered

As indicated previously, I added Type=exec to the unit definition

Additional context

I've not tested this but adding sd-notify as a dependency might fail on operating systems other than unix/linux?

[Koenkk]

Looks good, please create a PR to update the docs.

[IgnacioHR]

Thanks, I'll do for the type=exec proposal but I'm not familiar with the source code so I can't provide a complete solution for type=notify and this is why I added a feature request.

[rpakdel]

Hey guys, is this guaranteed to work on all systems correctly? I can confirm latest master does not notify systemd for me and causes Zigbee2MQTT to be repeatedly restarted leading to delayed device response and high cpu usage spikes. I’ve lost countless hours trying to narrow down the reason for this over the past month.

• Migrated from RPI2 to RPI3B+ in January after many years of trouble free usage.
• Fresh Raspbian install.
• Ran update.sh before posting to confirm latest codebase.
• Installed systemd-dev dependency
• Using Type=notify causes systemd to terminate and restart after timeout
• Using Type=exec starts and runs without issue

I’m wondering if the default service configuration example in the docs should be the simpler exec type with notify as an advanced option?

[IgnacioHR]

I’m on my cell phone right now. Please verify you have installed the “new additional” requirements at the op system level libsystemd-dev

[rpakdel]

apt list --installed | grep libsystemd
...
libsystemd-dev/oldstable,oldstable-updates,now 247.3-7+deb11u4 arm64 [installed]
libsystemd0/oldstable,oldstable-updates,now 247.3-7+deb11u4 arm64 [installed]

[IgnacioHR]

Good!

Think this the other way around. The new starting method notify is working as expected. z2m is not properly starting and the op. system is trying to start it again. Now, notice what other changes you did during the update process. For example, Are you using a port for the web server that requires privileges? In my case I'm using port 443 and this requires to tell the op system that node has permission to use it. Also notice the change in the ExecStart changed from a shell script to node directly.

Activate your logs to see what might be happening and think that the new starting procedure is working for you

[IgnacioHR]

BtW, I'm going to close this issue as it is already implemented

[rpakdel]

Thank you for the reply. This is resolved for me as far as I’m concerned by using Type=exec and removing the watchdog timeout. This is just FYI for anyone who might later run into issues.

• Fresh install of Raspbian
• Custom username (not using pi, but ensured it is added to dialup group per another thread)
• Followed instructions on the website
• No special ports or configuration
• Runs on wired LAN with no outside access
• Disabled file logging because I was looking for source performance spikes and also I want to lengthen the SD card life.

While I was annoyed at the lost time, I highly appreciate the work you have put into Zigbee2MQTT. I’ve been using it in combination with Node-RED for 4+ years for my home automation. The fact that I’ve freely enjoyed the fruits of your hard work is not lost to me.

kind regards