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.
This is the result of the command. I see no obvious conflict
pi@raspberrypi:~ $ 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 [::]:*
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
sudo systemctl stop ha-bridge.service
sudo systemctl stop homegenie.service
sudo systemctl poweroff
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?
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.
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)
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.
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):
/etc/systemd/system and perform the modifications on the copy. This file will completely override the file in /usr/lib./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
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.
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: pi@pts/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
The service is created by way of Symlink to the startup.sh script as highlighted below
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.
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/
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…
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.
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.
pi@raspberrypi:/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
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…
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.
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.
I’m not sure what you are comparing what to or what context you are quoting from.
If you research back you will see that the HG installer broke when Raspbian Buster was introduced.I managed to create a list of simple commands that safely removed the offending dependencies. This in turn required the user to create a Homeseer service, the one you are now referring to as one was not automatically created.
That continued for about a year until the author revisited HG and corrected his package installer. That in turn allowed the installer to continue to execute until the startup script was created.
If you install HG via the manual install instructions an auto start script is not created.
We are where we are now and the gdeb package installer works fine so my workaround is no longer an issue.
I’m assuming you now have a handle on your dilemma with which service is grabbing port 80 first.
Pete, It may be difficult for you to see this entire process from my perspective as a noob to the entire HG/HA project, let alone Alexa. I have tried to find the latest threads on everything to install the latest and greatest available. I think I have done that. Using all the installers described I ended up with NO homegenie.service that was easily detected/found.
When you suggested the timing delay and to update the homegenie.service, I went looking and was totally shocked to not be able to locate it.
This led to the rabbit hole I just described above. I’ve been at this for hours because I could not find anything that clearly described the same situation I was finding.
The startup script you describe is not the homegenie.service script that people use systemctl to start/stop homegenie with, at least not directly.
FYI if you deleted your homegenie.service file and let the OS generate it’s own homegenie.service file, it creates one that does a fork among other options. This is not how you likely run your homegenie and not something I’ve seen mentioned much as a standard option to set for a simple install like mine.
This is what is auto-generated and many probably start/stop their Homegenie with for the past few years…
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/homegenie
Description=LSB: Run HomeGenie
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=all.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/homegenie start
ExecStop=/etc/init.d/homegenie stop
To paraphrase from the link I sent you…
Here are the main differences between the two. SystemV is older, and goes all the way back to original Unix. SystemD is the new system that many distros are moving to. SystemD was designed to provide faster booting, better dependency management, and much more.Dec 5, 2019
HG started out with the SystemV system and as far as I’m aware a symbolic link to Systemd is created along the lines of this link https://unix.stackexchange.com/questions/194175/can-i-use-a-symbolic-link-as-a-service-of-systemd
If you want to start a fresh post with all your findings you should do so. I’m assuming you have resolved your initial issue or a well capable of doing so.
If you are not happy with aspects of how HG installs or operates open an issue on the author’s GitHub
It’s been a long day and time for family now