Systemd Service for homebridge (http://github.com/nfarina/homebridge)

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=*

homebridge.service

[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

After trying million ways to get it work i finally, hopefully, managed to get rid of the "homebridge.service: Main process exited, code=exited, status=1/FAILURE". In the Homebridge defaults (etc/defaults/homebridge) you have to put HOMEBRIDGE_OPTS= the real config.json file folder. For me it was: HOMEBRIDGE_OPTS=-I -U /home/pi/.homebridge. Hope it helps!

I have a problem. The Homebridge can't find the config.json.
My /etc/systemd/system/homebridge.service is:

[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

The homebridge file is the same file with no changes.
When i try to run homebridge manually it works.

pi@piHomebridge:~ $ sudo su - homebridge
No directory, logging in with HOME=/
$ bash
homebridge@piHomebridge:/$ /usr/bin/homebridge -U /var/lib/homebridge

Output:

[7/3/2019, 20:48:38] Loaded config.json with 1 accessories and 0 platforms.
[7/3/2019, 20:48:38] ---
[7/3/2019, 20:48:38] Loaded plugin: homebridge-wol
[7/3/2019, 20:48:38] Registering accessory 'homebridge-wol.NetworkDevice'
[7/3/2019, 20:48:38] ---
[7/3/2019, 20:48:38] Loading 0 platforms...
[7/3/2019, 20:48:38] Loading 1 accessories...

The directory is okey

homebridge@piHomebridge:/$ ls -l /var/lib/homebridge/
total 12
drwxrwxrwx 2 homebridge homebridge 4096 Jul  3 18:29 accessories
-rwxrwxrwx 1 homebridge homebridge  460 Jul  3 20:01 config.json
drwxrwxrwx 2 homebridge homebridge 4096 Jul  3 20:02 persist

But when i try to start the homebridge deamon with sudo systemctl start homebridge it not starts correctly.
journalctl -u homebridge shows:

...
[7/3/2019, 18:36:58] config.json (/var/lib/homebridge/config.json) not found.
...

How i can fix this problem ?

If you already added your homebridge/accessories in the Home App before migrating to systemd, then you will need to copy the files from your ~/.homebridge/persist to /var/lib/homebridge/persist. This is what fixed the issue of the Home app not responding to any accessories or the homebridge hub.

@codenko & @kevince52

Verify that the path is accurate -- I had to add word "local" to the path in homebridge.service file.
ExecStart=/usr/local/bin/homebridge $HOMEBRIDGE_OPTS

That ended up being my issue as well. I could manually start my second instance, but the service would not run. I had to change /usr/bin/homebridge to /usr/local/bin/homebridge and everything started working.

hello,
i followed the new instructions to install homebridge on raspberianOS, but i seem to fail to understand how to fix this error:
systemctl enable homebridge => update-rc.d: error: homebridge Default-Start contains no runlevels, aborting.

Any solutions?

Hello everyone! I want to run Homebridge in insecure mode.
Now from terminal i have to do homebridge -I.

How can I implement it in the bootup script? Thanks :)

I got mine to work by editing the /usr/local/bin/homebridge and instead of using strict, changed to use insecure and it worked just fine

@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.

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!