Have a task run multiple times?

[hongkongkiwi]

I am looking to emulate something like ifup/ifdown functionality with finit. So I would like to run a task everytime a signal is set (e.g. the net/eth0/up signal)

From my understanding, tasks only run once and then if they have success they do not run again ? (is that correct?)

Is it worth adding a issue/feature request so that a task can run repeatedly everytime the signal is triggered? (I guess it would be something like repeat:yes ?)

[troglobit]

Hmm, very interesting, let me get back to you on that one. I'll write a test case and play around with it a bit, maybe it already works ...

[hongkongkiwi]

Just one little thing I'm worried about -- semantics. When conditions are set and script/program is started, there's a risk of not being able to start+execute+collect the process before the condition is asserted/deasserted again. Would it be OK with you if this is best effort, or do you expect conditions to be enqueued and delivered in order, pending the exit of each instance of the script/program? Because the latter is a lot of more work

Yea, I agree, I don't think queueing makes sense. If I understand your concern above, what about if each event can only be run one instance at a time? For example, lets take a script that runs when multiple network instances come up:
event <net/eth0/up,net/eth1/up> eventscript

If the event script is already running because eth0 came up (and lets say our event script is really slow and does lots of things without finishing), and then eth1 comes up, we shouldn't run this again or do anything, just ignore any additional signals because the event script has been triggered and hasn't finished. Once the event script is finished running it can be triggered again if another event comes true.

If the user really wants to handle lots of small events with one script then they could separate out multiple event scripts e.g.

event <net/eth0/up> eventscript eth0
event <net/eth1/up> eventscript eth1

This would run that script multiple times because the eventscript because it's two separate lines and thus two separate events.

Ok if we use the same example above with conditions assert/deassert it also works:
event <+net/eth0/up,-net/eth1/up> eventscript

So this would run whenever the interface goes up or down, so if the interface goes up, script runs and takes a long time to run (e.g. it's sleeping for 5 minutes) then interface goes down, the script wouldn't be triggered again, unless the script ran and finished before the next event is triggered.

So, following on from this, I suppose we need to be able to stop events, so probably events should be able to be killed by an initctl command incase they end up in an endless loop or something and the user wants to stop it.

[hongkongkiwi]

I slept on it and thought that there might be a small but significant difference between event and other types:
service -> goes up when signals are set, goes down when signals are cleared
task -> triggers when signals are set (runs once)
event -> triggers when signals are set (triggers whenever the set of signals match), (see note about sync or async below)

Now, with task, or event negative signals say (<-/net/route/default,+/net/route/default> work fine as these would be triggered whenever a default route is lost or gained.

For event type, it might make sense to have an async flag, that way it will just run it whenever the event is triggered, and won't check if the event script is already running. I guess that's what you were thinking above. To save complexity perhaps this could be the default and the even script could check a lockfile (and fail) if it needed to only run one at a time. In future it could be extended so the user has the option to make a sync (run only once instance at once) or async event (run multiple instances at once).

Definitely no queueing. I think if the user really needed high frequency events they would probably use something like mqtt or kafka, I just can't imagine too many situations where that makes sense compared to having a dedicated daemon to handle it (maybe my imagination is limited there!)

[troglobit]

Phew, thanks! This would really make implementing this easier 😃

Ah, multiple conditions. This is another limitation that's worth mentioning at this stage. The current implementation is limited to logical AND of multiple conditions. So for your above examples, the script would not run until all conditions are satisfied. We toyed early on with the idea of supporting logical OR as well, but we realized quickly it wouldn't stop there. What's possible though is 1) logical AND of multiple conditions (as above), and 2) a logical OR using multiple lines, sort of what you are onto above.

However, Finit relies on the script/program name to uniqify it's run/task/services, so with your example one would have to write:

event :1 <net/eth0/up> eventscript eth0
event :2 <net/eth1/up> eventscript eth1

or

event :1 <+net/eth0/up,-net/eth1/up> eventscript primary
event :2 <-net/eth0/up,+net/eth1/up> eventscript secondary

From what I've seen in the past, these type of constructs is usually enough. So all we need is implemented event types and expose the +/- polarity for condition matching.

I intend for events to under the hood be implemented just as a variant of tasks, so initctl stop eventscript:1 or initctl signal ... would work as expected.

[troglobit]

I slept on it and thought that there might be a small but significant difference between event and other types: service -> goes up when signals are set, goes down when signals are cleared task -> triggers when signals are set (runs once) event -> triggers when signals are set (triggers whenever the set of signals match), (see note about sync or async below)

Now, with task, or event negative signals say (<-/net/route/default,+/net/route/default> work fine as these would be triggered whenever a default route is lost or gained.

For event type, it might make sense to have an async flag, that way it will just run it whenever the event is triggered, and won't check if the event script is already running. I guess that's what you were thinking above. To save complexity perhaps this could be the default and the even script could check a lockfile (and fail) if it needed to only run one at a time. In future it could be extended so the user has the option to make a sync (run only once instance at once) or async event (run multiple instances at once).

Definitely no queueing. I think if the user really needed high frequency events they would probably use something like mqtt or kafka, I just can't imagine too many situations where that makes sense compared to having a dedicated daemon to handle it (maybe my imagination is limited there!)

Hmm, I see where you are coming from here, but that's actually quite tricky. Finit is a responsible PID 1, tries to be at least, and takes care to monitor all processes it starts. Monitoring PID files and running everything in the foreground to catch them if they die ... but I'll think about it, and talk it over with my colleague today, because you could be on to something here and I'm just on my first cup of coffee ☕ here 😪

Yes, I agree on the high freq events -- anything beyond the limited capabilities of Finit would haver to be a dedicated event daemon of some kind.

[hongkongkiwi]

Ah, logical AND makes sense, I sortof forgot that's how it worked for a moment. Perfect.