Can't get HA-Bridge to start on simple RPI-4 boot?

General
#1

I have tried multiple approaches to get HG and HA Bridge to start on reboot and every time HA-Bridge tries to start as an enabled service, it fails to find port 80. If I log in to command line as PI after reboot, HA-Bridge will start with no issues on port 80. HG starts fine every time on port 8090.

The log shows homegenie started, then trying to start HA Bridge but failing on port 80, then seemingly finding the listener is not working? Eventually closing HA Bridge.

I even changed the name of the HA Bridge service to zha-bridge.service as I read somewhere the services were started in alphabetic name, but that made no apparent difference.

I’m open to suggestions?
systemlog.zip (16.3 KB)

wpa_supplicant.service enabled
[email protected] disabled
x11-common.service masked
zha-bridge.service enabled
machine.slice static

Dec 14 14:08:35 raspberrypi homegenie[364]: homegenie started.
Dec 14 14:08:35 raspberrypi dhcpcd-run-hooks[457]: wlan0: starting wpa_supplicant
Dec 14 14:08:35 raspberrypi systemd[1]: Started Login Service.
Dec 14 14:08:35 raspberrypi systemd[1]: Started WPA supplicant.
Dec 14 14:08:35 raspberrypi systemd[1]: Started LSB: Run HomeGenie.
Dec 14 14:08:35 raspberrypi systemd[1]: Reached target Network.

Dec 14 14:08:35 raspberrypi systemd[1]: Started HA Bridge.

Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,497 [Thread-0] ERROR com.bwssystems.HABridge.HABridge - Could not start ha-bridge webservice on port [80] due to: Cannot assign requested address
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,499 [Thread-0] WARN com.bwssystems.HABridge.SystemControl - Error pinging listener. Network is unreachable (sendto failed)
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,503 [Thread-0] WARN com.bwssystems.HABridge.HABridge - {“control”:“stopping”}
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,526 [main] INFO com.bwssystems.HABridge.upnp.UpnpSettingsResource - Description xml service started…
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,539 [main] WARN com.bwssystems.HABridge.upnp.UpnpListener - UPNP Listener exiting as reinit or stop requested…
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,539 [main] INFO com.bwssystems.HABridge.HABridge - Going to close all homes

#2

How familiar are you with the systemd.service. You would probably need to start the HA Bridge service BEFORE homegenie.service.

I’m assuming before you are rebooting your Pi you are stopping both services.Try this first and report back.

#3

Also just to check what ports are listening type the following at the terminal prompt and paste the results

ss -tulw

#4

A quick way to delay the start of HG before HA Bridge starts is to add a sleep command to the homegenie.service as follows

[Service]
ExecStartPre=/bin/sleep 30

Again you need to confirm nothing else is grabbing port 80 on startup. Running that port check command I supplied above should confirm this.

#5

This is the result of the command. I see no obvious conflict
[email protected]:~ $ ss -tulw
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
raw UNCONN 0 0 :ipv6-icmp :
udp UNCONN 0 0 0.0.0.0:1900 0.0.0.0:
udp UNCONN 0 0 0.0.0.0:1900 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:bootpc 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:sunrpc 0.0.0.0:*
udp UNCONN 0 0 127.0.0.1:54971 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:56520 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:50000 0.0.0.0:*
udp UNCONN 0 0 :dhcpv6-client :
udp UNCONN 0 0 :sunrpc :
udp UNCONN 0 0 :36583 :
udp UNCONN 0 0 :mdns :
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:
tcp LISTEN 0 25 127.0.0.1:33847 0.0.0.0:
tcp LISTEN 0 500 0.0.0.0:8090 0.0.0.0:
tcp LISTEN 0 4096 0.0.0.0:8188 0.0.0.0:
tcp LISTEN 0 128 0.0.0.0:sunrpc 0.0.0.0:*
tcp LISTEN 0 50 192.168.1.141:http 0.0.0.0:*
tcp LISTEN 0 128 [::]:ssh [::]:*
tcp LISTEN 0 128 [::]:sunrpc [::]:*

#6

I am familiar with similar tools but not specifically systemd. I need to understand how to do exactly what you suggest, start one service before the other intentionally. I thought I read that systemd decides to do them alphabetically which is why I renamed the HA Bridge service zha-bridge.service, but that made no difference. How do I force one to start before the other?

Yes, I created a simple shutdown script to run before poweroff.
#!/bin/sh

Usage: Shutdown.sh

Example: Shutdown.sh /usr/local/bin/homegenie

sudo systemctl stop ha-bridge.service

sudo systemctl stop homegenie.service

sudo systemctl poweroff

#7

Since these 2 programs actually run independently of each other, I thought starting HG first was the best order, then HA. Obviously HA uses HG to complete the calls/commands, but it runs independently. Manually, I can start/stop either one in either order and they both work fine. It was just at reboot where it seems like port 80 isn’t available at the moment HA wants to use it?

#8

Assuming you have nothing else installed on your RPI other than HG and HA Bridge there’s no reason why HA Bridge won’t start on port 80 other than the fact that when HG starts first it will always check the availability of port 80 even though it’s redirected to a different port. Possible collision between the two services.

That’s why I suggest putting a sleep instruction into your HG service file to ensure HA Bridge is fully up and running before HG attempts to start.

#9

I’ve always started HA-Bridge first as it requires port 80 to work correctly with Alexa and have had no problems.
Since HG checks port 80 availability first I suspect the pi os isn’t releasing port 80 before HA-Bridge tries to use it.

If you really wish to load HG first do as @Petediscrete suggests it should work, it makes for a slower load (however not by much)

#10

A 30 second sleep command as I suggested. That can be adjusted accordingly depending on the users preferences.

HG polls all available ports starting at port 80. Depending on port response speed HA Bridge will see this port interrogation as port 80 in use and will shutdown its processes.

I don’t use HA Bridge but as it’s a server it will act as any other server. Adjustments can be made to its service daemon to reflect possible conflicts in a similar way to HG service daemon.

#11

OK, so I can appreciate starting HA first and have no problem doing that, but from what you guys are saying, the ONLY apparent way to force this is to introduce the HG delay into the .service. I did some more investigations and this seems to be the way to force dependencies rather than try delay techniques. I will give it a try. Thanks for your input.

There are two alternatives to modifying the service file in /usr/lib/systemd/system (see Example 2. Overriding vendor settings):

  1. Copy the file to /etc/systemd/system and perform the modifications on the copy. This file will completely override the file in /usr/lib.
  2. Create the file /etc/systemd/system/smb.service.d/local.conf. The contents of the file should be something like the example below. This selectively overrides the “Requires” and “After” options in the vendor provided service file.

Each of these (including modifying the file in /usr/lib) offers advantages and disadvantages. The best choice may depend on the service and the nature of the modifications.

While it may work, it is not sufficient to only add the “After” option (see [Unit] Section Options). “After” controls order, but not dependencies. If dirsrv.target is not started in some other way, specifying an order will not start it. Use of the “Requires” or “Wants” option will force dirsrv.target to be started.

[Unit]
Requires=dirsrv.target
After=dirsrv.target
#12

The main objective is to get the HA Bridge up and running on port 80 prior to any other service attempting to access it while its not in use. You can assign a port in the HG UI but HG is known to grab the next available port. If port 80 is not available that’s your issue resolved.

There are many ways to achieve this. In fact both of the services could be launched from one single service daemon.

If you haven’t already examined the contents of the HG service daemon I suggest you do so. You can tailor it to your own requirements. The HA Bridge service daemon is quite basic and can also be adapted to your own needs.

Either way once both services are behaving as they should you’ve achieved your goal.

#13

Pete, I have been searching in vain for the homegenie.service daemon and cannot find it in the normal locations! I know it has to be somewhere because I can still stop/start it with systemctl, but I’ve been looking in all the normal locations /etc/systemd/system, usr/local/bin/homegenie and I simply don’t see it. Not sure what happened. I don’t recall actually creating it so I am assuming it was done during the standard install. systemctl status shows this, but it hasn’t helped me locate the .service???

● raspberrypi
State: degraded
Jobs: 0 queued
Failed: 1 units
Since: Wed 1969-12-31 16:00:01 PST; 50 years 11 months ago
CGroup: /
├─user.slice
│ └─user-1000.slice
│ ├─session-23.scope
│ │ ├─ 826 systemctl status
│ │ ├─ 827 pager
│ │ ├─29493 sshd: pi [priv]
│ │ ├─29499 sshd: [email protected]/0
│ │ └─29500 -bash
│ ├─[email protected]
│ │ └─init.scope
│ │ ├─616 /lib/systemd/systemd --user
│ │ └─617 (sd-pam)
│ └─session-1.scope
│ ├─485 /bin/login -f
│ └─628 -bash
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─alsa-state.service
│ └─403 /usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon
├─systemd-timesyncd.service
│ └─318 /lib/systemd/systemd-timesyncd
├─homegenie.service
│ ├─30764 /bin/sh /usr/local/bin/homegenie/startup.sh /usr/local/bin/homegenie
│ ├─30766 sudo /usr/bin/mono HomeGenie.exe
│ └─30767 /usr/bin/mono HomeGenie.exe
├─dbus.service
│ └─417 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

#14

The service is created by way of Symlink to the startup.sh script as highlighted below

#15

What I don’t quite understand however is how the systemctl works to start a .service file called homegenie.service when I don’t find that service either in /usr/local/bin/homegenie/ or anywhere else? I don’t know how to edit the homegenie.service object if I can’t find it?

ls -ltr on /usr/local/bin/homegenie/ shows no symbolic link to a homegenie.service file anywhere. What directory should I be looking for the actual homegenie.service file in?

I am missing something very basic and it really irritates me that I can’t find the answer. Appreciate your help.

#16

Have a read of this. It should explain the difference between the two systems and how they interoperate https://www.2daygeek.com/sysvinit-vs-systemd-cheatsheet-systemctl-command-usage/

#17

Pete, I’m not quite sure why you sent me to an explanation of how systemd works and the systemctl commands that are available. That does not really help explain where the homegenie.service file is located.
I’ve poured over many threads trying to understand where the .service file is including a response you posted here. I’ve looked in this location and I currently can’t find my homegenie.service file there. My files are listed at the end of this entry…

  1. In order to start HomeGenie automatically each time we need to create a homeseer.service file

sudo nano /etc/systemd/system/homegenie.service

This brings you into the Raspbian file editor. Just copy/paste the following onto the top line of the screen

[Unit]
Description=Homegenie Server
After=network.target

[Service]
WorkingDirectory=/home/pi/homegenie
ExecStart=/usr/bin/mono /home/pi/homegenie/HomeGenie.exe --log
Restart=always

[Install]
WantedBy=multi-user.target

As soon as you have copy/pasted press the Ctrl-X keys and then press Y and Enter.

  1. You need to enable the HomeGenie service so copy/paste the following

sudo systemctl enable homegenie.service

Now you need to start the service

sudo systemctl start homegenie.service

You can access HomeGenie in the usual way. It will have been installed on Port 80 as a new install.

[email protected]:/etc/systemd/system $ ls -l
total 64
-rw-r–r-- 1 root root 1551 Sep 9 03:17 [email protected]
drwxr-xr-x 2 root root 4096 Dec 2 04:41 bluetooth.target.wants
lrwxrwxrwx 1 root root 42 Dec 2 04:41 dbus-fi.w1.wpa_supplicant1.service -> /lib/systemd/system/wpa_supplicant.service
lrwxrwxrwx 1 root root 37 Dec 2 04:41 dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service
lrwxrwxrwx 1 root root 40 Dec 2 04:41 dbus-org.freedesktop.Avahi.service -> /lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root 45 Dec 2 04:37 dbus-org.freedesktop.timesync1.service -> /lib/systemd/system/systemd-timesyncd.service
lrwxrwxrwx 1 root root 37 Dec 5 14:48 default.target -> /lib/systemd/system/multi-user.target
lrwxrwxrwx 1 root root 34 Dec 2 04:41 dhcpcd5.service -> /lib/systemd/system/dhcpcd.service
drwxr-xr-x 2 root root 4096 Dec 5 14:48 dhcpcd.service.d
drwxr-xr-x 2 root root 4096 Dec 5 14:48 getty.target.wants
drwxr-xr-x 2 root root 4096 Dec 5 14:48 [email protected]
-rw-r–r-- 1 root root 295 Dec 14 11:28 ha-bridge.service
drwxr-xr-x 2 root root 4096 Dec 2 04:40 halt.target.wants
drwxr-xr-x 2 root root 4096 Dec 15 08:37 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Dec 2 04:38 network-online.target.wants
drwxr-xr-x 2 root root 4096 Dec 2 04:40 poweroff.target.wants
drwxr-xr-x 2 root root 4096 Dec 2 04:41 rc-local.service.d
drwxr-xr-x 2 root root 4096 Dec 2 04:40 reboot.target.wants
drwxr-xr-x 2 root root 4096 Dec 2 04:41 remote-fs.target.wants
drwxr-xr-x 2 root root 4096 Dec 11 15:36 sockets.target.wants
lrwxrwxrwx 1 root root 31 Dec 5 14:49 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x 2 root root 4096 Dec 2 04:41 sysinit.target.wants
lrwxrwxrwx 1 root root 35 Dec 2 04:38 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Dec 2 04:38 timers.target.wants

#18

Pete, nevermind I found the homegenie.service under /run/systemd/generator.late/homegenie.service. Not sure how it got here and if I can remove it or move it. Your article above did nothing to identify this location…

#19

I wasn’t posting that link to identity the location of your service daemon. I was purely pointing to how the HG author constructed his service daemon with the forerunner of systemd.

HG is now 7 years old but retained the old service daemon file system

A much simpler Systemd service file could be deployed to launch HG. I’m sure you’ll figure it out yourself.

#20

But Pete, that wasn’t an answer to my basic question What directory should I be looking for the actual homegenie.service file in? Answering that basic question with “I don’t know” would have been more productive to start with.

Regardless, I now understand that the current installation of HG creates a file in /etc/init.d/ named homegenie. In the current version of the Rasberian PI OS, if no specific homegenie.service file is found in the normal locations like /etc/systemd/system or /usr/local/lib/systemd/system the systemd will auto-generate a homegenie.service file and place it into /run/systemd/generator.late/ on EVERY REBOOT. This means it can be found by systemctl for start/stop purposes, but it gets recreated each time the OS is rebooted.

Now if you happen to follow one of the many threads on this site or others that suggest creating your own homegenie.service in /etc/systemd/system/ like Petediscrete suggested in the past, then your copy would override any systemd generated copy of homegenie.service that might exist in /run/systemd/generator.late/

Be aware: There is also a hierarchy of which directory gets looked at first so if you ended up with 2 copies of homegenie.service, one in /etc/systemd/system and one in /usr/local/lib/systemd/system, the one in /etc/systemd/system would take precedence.