-
-
Notifications
You must be signed in to change notification settings - Fork 60
Have a task run multiple times? #239
Replies: 1 comment · 10 replies
-
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 ... |
Beta Was this translation helpful? Give feedback.
All reactions
-
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: 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.
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: 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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
I slept on it and thought that there might be a small but significant difference between event and other types: 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!) |
Beta Was this translation helpful? Give feedback.
All reactions
-
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:
or
From what I've seen in the past, these type of constructs is usually enough. So all we need is implemented I intend for events to under the hood be implemented just as a variant of tasks, so |
Beta Was this translation helpful? Give feedback.
All reactions
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
Ah, logical AND makes sense, I sortof forgot that's how it worked for a moment. Perfect. |
Beta Was this translation helpful? Give feedback.
All reactions
-
🎉 2
-
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 ?)
Beta Was this translation helpful? Give feedback.
All reactions