Skip to content

Instantly share code, notes, and snippets.

@johannrichard
Last active May 23, 2024 16:15
Show Gist options
  • Save johannrichard/0ad0de1feb6adb9eb61a to your computer and use it in GitHub Desktop.
Save johannrichard/0ad0de1feb6adb9eb61a to your computer and use it in GitHub Desktop.
Systemd Service for homebridge (http://github.com/nfarina/homebridge)
# Defaults / Configuration options for homebridge
# The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others)
HOMEBRIDGE_OPTS=-U /var/lib/homebridge
# If you uncomment the following line, homebridge will log more
# You can display this via systemd's journalctl: journalctl -f -u homebridge
# DEBUG=*
[Unit]
Description=Node.js HomeKit Server
After=syslog.target network-online.target
[Service]
Type=simple
User=homebridge
EnvironmentFile=/etc/default/homebridge
# Adapt this to your specific setup (could be /usr/bin/homebridge)
# See comments below for more information
ExecStart=/usr/local/bin/homebridge $HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target
@esgie
Copy link

esgie commented Nov 1, 2020

@kaaspad I too would like to know why the separate homebridge user is necessary, however from my experience it really is. I'd initially set up homebridge with the config.json in /home/pi/.homebridge. After some initial success, homebridge failed to run at boot time. I could still run it directly (just typing "homebridge"), but it failed to start when using systemctl. Looking at the errors, it appeared to be related to not being able to access the persist directory.

Changing to a separate homebridge user and putting the config.json in /var/homebridge (and having that directory owned by and writable by the homebridge user) fixed things.
Except of system services, systemd supports something that is called „user services” aswell.
The .service file (in the very same format as for system service, execpt the „user” property which should be omitted) are to be placed in /lib/systemd/user
Then, the service can be controlled (started, enabled, etc.) via sysctl by a regular user like pi.
Creating separate users have some sense when the service must be run with root privileges for some reason (like opening listen socket on port below 1024), amd usually after completing root actions the ownership of the running service is dropped to that (unprivileged) user.
In case of homebridge, there is absolutely NO need of running it with root privileges UNTIL you do not use plugins which require some elevated privileges. That is why running homebridge as a system service in most cases is not really required, in fact it creates some additional security risk.
I’d stick with user service (see first paragraph) or run homebridge via node’s pm2 manager which is more than comfortable.

@VMicha
Copy link

VMicha commented Nov 7, 2020

Note for systemd users: Your start service needs to start the NetworkManager-wait-online.service before being able to wait after it is finished:

[Unit]
Description=Node.js HomeKit Server 
Wants=network-online.target
After=syslog.target network-online.target

See https://unix.stackexchange.com/a/126146 for details.

This was the solution for me - thank you fuerst!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment