I really need some help working out service dependencies in systemd. If anybody's got some time to answer a few questions, could you help me out?
No promises other than that I'll try.
@endomain Thank you very much.
Basically, I have a message bus that comes up as expected. But how do I get a couple of bots' service files to try to start over and over until they come up?
I'm not at my deck, so I can't paste links to the .service files at this second, give me a few minutes.
@endomain So, here's the .service file for my message bus. It works and is responsive: https://github.com/virtadpt/exocortex-halo/blob/master/exocortex_xmpp_bridge/xmpp_bridge.service
Here are the ones that didn't come up, possibly because they gave up before the message bus finished starting:
I know I'm doing something wrong in here, but after a couple of attempts I'm not sure what.
I think the pattern is After= and Requires=, not After= and Wants= ?
Wants= is a very soft statement compared to requires:
A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit.
Also, I just recalled this. The simple service type doesn't understand that your service has a startup time.
You can force a wait in your [Service] section for dependent units to cheaply work around this for now:
@endomain Hmmm... I can't necessarily predict how long it'll take for the message bus to come online due to my home link.
I just scanned through my code and didn't find any "bot can't reach message queue so it dies" code.
Is there a service type that does have a concept of a startup time?
Just to be complete: there is a notify type. You found it. Otherwise people use shell commands that block. For example if you write a pidfile you can shellloop on that pidfile containing a value.
@endomain Hmmm... that would require a bit more addition of code to the XMPP bridge. I think I'll try sd_notify first, and fall back on that if it's less stable.
@endomain What about a service type of "idle"?
"Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway."
You could. Or you could be lazy and use a static service type. I use the notify type in production when it's well supported by my runtime. Otherwise it's just one more potential bug.
A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.