Closed marcelstoer closed 4 years ago
This doesn't really have anything to do with Comitup. Look at systemd resrouces.
this may be a silly as it seems trivial, but have you tried comitup.service
?
This doesn't really have anything to do with Comitup.
Apart from the fact that I'm working on a comitup image, no, that's true 😉 I thought you might have a hint based on your knowledge of which services comitup depends upon.
have you tried
comitup.service
I had thought about it but not tried. I have since learned about systemd-analyze plot > plot.svg
(see below) and that's really helpful.
So, starting after comitup.service
is too early - at least for cases when the configured WiFi is available. My service (green) would start and detect that the connection to the AP hasn't been established yet.
Instead, starting after DHCP is just about right.
However, when no configured WiFi is available and comitup is in HOTSPOT mode my service does not start as the DHCP service is not started either - I guess. Remember I'm a bit blind here as I can't SSH into the Pi at this point and don't have a Micro-HDMI connector to see any output.
This is related to #116. Still working on dumping (network) information onto a display on startup as part of the application init sequence.
I had created a
systemd
service wrapping the Python code like so:It turned out that
multi-user.target
really isn't the right service to depend upon as my service wouldn't start when comitup was in AP mode.Which service do you suggest I depend upon so that my service starts after the comitup/NetworkManager initialization but regardless of whether the device is in client or AP mode? This should reduce the risk of my app running too early and then report it be not connected to the internet (I'm polling the comitup D-Bus state).