olad starting before network is functional

[Andrew Hall]

Hey, guys,

In dealing with Wi-Fi on the Pi Zero W (Raspbian Jessie Lite), I notice that frequently olad is started before the Pi connects to the AP and gets an IP address. I've been manually restarting olad after boot, but this is impractical once tech rehearsals start for my theater's play. It doesn't appear olad has a native systemd unit, which I think would make this easier. If there's a simple solution to this, great. If not, I'm going to attempt to hack together a systemd service file based on the init script. From what I read, $network in the LSB header is supposed to translate to network-online.target in systemd, but this doesn't appear to be happening in my case.

Andrew

[Peter Newman]

If you search the mailing list, there has been discussion on this before and I think maybe even some systemd service setups posted. Let us know if you get one that works and we can add it to the repository.

I think a lot of people fall back to the low-tech sleep for some time before actually starting olad. You could probably also do something clever like restarting it via ifup.d assuming it was running beforehand.

[Andrew Hall]

OK. I took a brief search through the mailing list and didn't find anything immediately useful. I'll look again, but I think I'm just going to try and make my own olad.service systemd unit. I'll post it here for review when I've gotten it working. It will be more robust than just "sleeping" for 15 seconds.

Andrew

[Peter Newman]

There's one here that Google found:

https://gist.github.com/s-light/fba54aa65b14a1da290f10dfa4e9dcae

[Andrew Hall]

Peter,

Yes, I ran across that one, though I didn't try it. I made one of my own. It does work, but it didn't really solve my issue.

After a lot of digging, I realized that systemd was indeed respecting "$network" in the LSB header of olad's init script. The issue was that systemd's network.target was simply being reached early. Why? Well, in raspi-config, you can set the Pi to wait for the network before proceeding with boot. As far as I can tell, this creates a systemd drop-in at /etc/systemd/system/dhcpcd.service.d/wait.conf:

[Service]
ExecStart=
ExecStart=/sbin/dhcpcd -q -w

The "-w" causes dhcpcd to wait until at least one interface obtains an IP address, and then it forks and runs in the background. systemd waits for this behavior, reaches network.target, and then continues booting. dhcpcd's default timeout for "-w" is 30 seconds, but I discovered that my router's DCHP server insists on taking about 45 seconds to offer a lease. By that time, olad has already loaded, albeit with a useless 0.0.0.0.

How did I solve this? For now, I've added "-t 60" to dhcpcd's wait.conf, forcing it to wait up to 60 seconds for an IP address. Here's my new wait.conf:

[Service]
ExecStart=
ExecStart=/sbin/dhcpcd -q -w -t 60

I may end up giving these Pi's static addresses to avoid this. I'd much prefer to let my router manage the addresses, but I have no idea why it's taking 45 seconds to "cough up" an IP address.

In summary, we don't actually need an olad.service systemd unit. I may still post mine later for completeness. It does have the benefit of being able to restart olad on failure.

Hoping this is helpful to someone,
Andrew

[Andrew Hall]

Here's the olad.service I came up with:

[Unit]
Description=Open Lighting Architecture daemon
Requires=network-online.target
After=network-online.target

[Service]
Environment="DAEMON_ARGS=--syslog --log-level 3 --config-dir /etc/ola"
EnvironmentFile=-/etc/default/ola
User=olad
UMask=0002
ExecStart=/usr/bin/olad $DAEMON_ARGS
Restart=always

[Install]
WantedBy=multi-user.target

[Andrew Hall]

I'm not 100% sure network-online.target is any better than network.target on the Pi, so perhaps this is sufficient:

[Unit]
Description=Open Lighting Architecture daemon

Requires=network.target
After=network.target

[Service]
Environment="DAEMON_ARGS=--syslog --log-level 3 --config-dir /etc/ola"
EnvironmentFile=-/etc/default/ola
User=olad
UMask=0002
ExecStart=/usr/bin/olad $DAEMON_ARGS
Restart=always

[Install]
WantedBy=multi-user.target

Note: You may prefer that the Restart directive be "on-failure" or "on-abnormal" rather than "always".

Andrew

[Peter Newman]

If restart is set to always, what happens if you stop olad via the web UI, does it relaunch anyway?

It sounds like this is tested, do you want to open a pull request to get it in (and claim the credit)?

[Andrew Hall]

Peter,

I tested it briefly, and it worked fine. If olad is shutd own from the Web UI, it is immediately restarted by systemd (with "Restart=always"). Again, this may not be ideal. Just change it to "Restart=on-failure" and it behaves more like the original init script. I don't want/need any credit for the unit; take it and integrate it if you want. As I said before, the systemd service is not technically needed, as systemd has legacy support for init scripts.

To be clear, my problem with olad starting before a DHCP lease was obtained was not solved by making this olad.service unit; I had to change the dhcpcd's timeout—this is not something I could solve by clever dependency requirements in olad.service.

Andrew