troglobit / finit

Fast init for Linux. Cookies included
https://troglobit.com/projects/finit/
MIT License
621 stars 61 forks source link

<task/<NAME>/failure> should also set error code in condition #276

Closed hongkongkiwi closed 1 year ago

hongkongkiwi commented 2 years ago

It would be great if when a task fails, that we can set a condition based on the failure code. This way specific scripts can be done to deal with the results.

For example, lets say we have a script which checks whether a hardware has failed. It can return 0 (success) or (failure) with exit code 1,2,3 so it would be great if for example it failed with error code 1 then it set both <task/<NAME>/failure> and <task/<NAME>/failure:1> error code 2 would look like: <task/<NAME>/failure> and <task/<NAME>/failure:2> etc

This would allow specific scripts to run if you know in advance what the error code might be. If you don't know, you can still using the existing <task/<NAME>/failure>condition.

hongkongkiwi commented 2 years ago

clearing conditions then might be slightly more tricky than currently, you would have to do (if in bash): rm -f "/run/finit/cond/task/<NAME>/failure" && rm -f "/run/finit/cond/task/<NAME>/failure:"*

troglobit commented 2 years ago

No, that's not what the conditions system is supposed to do. Not to mention the unnecessary complexity it would add.

I'd much rather see we handle this as part of #273 instead.

hongkongkiwi commented 2 years ago

So your thinking is that with the above fix, there can be a catchall script run upon failure which then checks the errorcode using initctl -s status and takes action that way?

troglobit commented 2 years ago

Yes exactly, 1) task failed, start script, 2) check exit status (and/or state) of task. This moves a lot of the logic to initctl, instead of squeezing it into PID 1.

Does that make sense for your use-case?

hongkongkiwi commented 2 years ago

Yep, that would work fine thanks!

troglobit commented 1 year ago

The post: script action and the just pushed f4d3cf2 should be sufficient for this issue. See #273 for more information.