Thanks for insight.
On 5/13/26 20:27, Laurent Bercot wrote:
The problem is that while such long oneshot script is running, s6-rc
blocks or fails (because main lock file is busy). Was it a conscious
choice to prevent any s6-rc command while oneshot service is running?
It's not tied to the length of your oneshot, it's tied to the fact that
(this version of) s6-rc is not reentrant. It is a conscious choice to
prevent two "s6-rc change" commands from running concurrently, because
conflicts in the service transitions would be difficult to manage.
So currently it means that if I want to reboot while such oneshot
service is not yet done – the reboot procedure will be delayed or I will
have to kill the offending process in the reboot script. That's ok, but
is somewhat inconvenient.
Just posting it FYI that rebooting while supervision tree wasn't yet
settled is kinda tricky and may or may not work as expected (at least
for me).
Obviously I can just run script in the background and call it a day, my
question is conceptual, do you think oneshot services are a good fit for
scripts that can take long time to execute?
It may or may not be a good fit. The real question is: is your script
providing something that can be understood as a service? Once it has run,
is it plausible to consider that something is "up"? Is there value in
running "s6-rc start foobar" rather than "foobar"? Do you need to
integrate foobar in your dependency graph when starting the machine?
That, more than the time that it takes to run, is what should inform
your decision.
It is something to think about. Setup is kinda complex: I have a longrun
"A" that does "s6-rc start foobar", and then it receives special events
about progress of "foobar" (using ftrig), but in the future I expect
some other longruns might want to be started only after "foobar"...
Have a nice day,
--
Alex
