Add support for soft dependencies

[troglobit]

Real life example: user starts lldpd and is happy. A few days later user starts snmpd and wants to be equally happy, but snmpd was never a requirement for lldpd to run so user is no longer happy because expected lldpd to restart and connect to snmpd over Agent-X protocol.

This issue details a feature request to Finit for "soft dependencies" to service stanzas. The idea is, as laid out in the ingress, to be allowed to start a daemon without a soft dependency but to restart it if a soft dependency is introduced. This could maybe be realized by simply inspecting the registered services, if a dependency is not registered, then simply ignore the dependency the user knows best after all, but if it is registered then take it into account like anything else.

Example:

service [2345] <pid/snmpd> /sbin/lldpd -- IEEE 802.1AB LLDP daemon

When snmpd is not an enabled service this results in:

service [2345] /sbin/lldpd -- IEEE 802.1AB LLDP daemon

When snmpd is enabled, and initctl reload is called, lldpd is also updated to become:

service [2345] <pid/snmpd> /sbin/lldpd -- IEEE 802.1AB LLDP daemon

[troglobit]

Mr Sleepyhead here managed to reference the wrong issue in the above commits. I intended to reference issue #44 ... 🤦‍♂️

[hongkongkiwi]

This is a very old issue, but just a thought, soft dependencies could naturally be done if we had a condition cleared and condition set extension (that we talked about using for events), so in the case of a soft dependency, you could set both conditions e.g.

<-+usr/mycondition> this means that it would start when either usr/mycondition is clear or set. But if it changes state it would restart the service.

[troglobit]

Intriguing, yes that could a very elegant solution to this! Thanks 😃

[hongkongkiwi]

I came up across a situation yesturday which made this useful.

Basically I had mdevd and syslogd running, the idea is I want syslogd to be running before mdevd, so I added a condition and it works fine.

Then I changed the config of syslogd and it ended up crashing and mdevd was also taken down by finint because of the condition. So a soft dependency could ensure it's started first as intended, but could also ensure it's not taken down if the other one is.

[troglobit]

Maybe I've not had enough coffee yet, but that's not the use-case I was after with soft deps. The basic idea was about being able to write service.conf files beforehand, listing possible all deps, but it a dependency is not available at runtime (finit can't find it in the active configuration set) the dependency is discarded.

[hongkongkiwi]

I see, yea my interpretation was definitely slightly different. I added #264 for a feature I'm looking for.

I can see your take on soft deps being valuable. From what you've said, perhaps it could boil down to being able to signal another service via a reload command to that service if this service goes up or down, and as finit is already configurable on how each service handles a reload.

An example config could be something like:

service [12345789] <service/REQUIRED/runnning> [service/OPTIONAL/running] mycoolservice

So anything in [] could be soft deps as you described. That means that if the condition service/OPTIONAL/running changes state (stops or starts) then this service mycoolservice gets a reload, but is not taken down. If the service in [] is not running at launch it doesn't matter, and ofcourse if it gets started later then mycoolservice is notified.

Just a thought on how this could be implemented :)

[hongkongkiwi]

This is nice and generic and can extend to any condition.... e.g.

service [12345789] <service/REQUIRED/runnning,usr/mustbeset> [usr/something_happened] mycoolservice

That means that we can take note of usr/something_happened without being bound by it we can just trigger when it changes to set or not set.

[troglobit]

I'll have to think about that, still feels like you're after something different from what this issue tries to describe. Soft deps should be automatically handled, the user shouldn't have to declare them. Also, less importantly, the [] is reserved for runlevels, I guess most of what you mention should probably be done in the new .conf format #148