Add condition for crashing services

[troglobit]

A failing run/task can be detected using conditions task/foo/failure, similar support for services would be very useful.
See below discussion.

Discussed in #245

^{Originally posted by hongkongkiwi April 23, 2022}
Is it possible to add a condition that’s automatically set when a service crashes? e.g <service/myservice/crashed> And additionally <service/myservice/running> ?

I’ve been testing respawn feature but I find I would like to handle crashes and attempt to fix the situation in some cases (E.g restore default mosquito config).

I think this feature could mean you don’t need to extend oncrash: later because a task (or event) can be setup to handle the case of a crash and run a script (or reboot) via the built in signal mechanism

[hongkongkiwi]

Suggested to add for the whole lifecycle, e.g.

service/<name>/ready
service/<name>/starting
service/<name>/setup
service/<name>/running
service/<name>/crashed
service/<name>/stopping
service/<name>/stopped

and any others

Although starting, setup, stopping are only there for a short time, it might be the appropriate time to trigger a task for some cases.

[troglobit]

Hmm, gut feeling says no, I'm worried opening up the internal states as an external "ABI" might make it real difficult to change the internals going forward. Sure; running, crashed, and stopped are sort of end states that will always be there. So them I can add.

[hongkongkiwi]

Fair enough, makes sense to keep it trim.

[troglobit]

Pushed the first implementation last night. When I arrived at the office earlier I was thinking about changing the namespace/prefix from service/ to svc/, not sure though. There's some benefit to aligning the namespace with the .conf setting, I guess.

[hongkongkiwi]

If you want my thoughts on the naming....

I can see what your thinking as svc is short and looks good, it makes it readable when you have lots of conditions... but I guess your not going to change task to tsk right? ;)

To be honest I quite like the current naming because it's really clear what service the condition associated with, and in future if you add extra types then you know clearly what the condition is matching.

[troglobit]

That was exactly my reasoning as well, plus it's shorter in multi-condition listings. Naming things is suuuuper hard though, and this in particular, because it is one of the things that will survive the big .svc syntax change planned in #148 ... sooooooo yeah. I need to make up my mind before though before the v4.3 release -- try to not uproot users too much between releases. But maybe we'll do #148 in Finit 5, and then we can overhaul the condition namespace as well .. Gah! 🤣