You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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.
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 :)
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
Activity
Extend .conf syntax for 'log' option, issue #21
Add support for redirecting output to a file using logit, issue #21
Add support for configurable redirect to /dev/null, issue #21
troglobit commentedon Jan 15, 2018
Mr Sleepyhead here managed to reference the wrong issue in the above commits. I intended to reference issue #44 ... 🤦♂️
hongkongkiwi commentedon May 9, 2022
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 commentedon May 9, 2022
Intriguing, yes that could a very elegant solution to this! Thanks 😃
hongkongkiwi commentedon May 10, 2022
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 commentedon May 10, 2022
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 commentedon May 14, 2022
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:
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 commentedon May 14, 2022
This is nice and generic and can extend to any condition.... e.g.
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 commentedon May 14, 2022
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