>From what I understand after reading documentation it is considered a
>bad idea to interrupt oneshot service (and any program for that matter
>that uses sudod), because for example it can escape supervision or
>potentially leave system in some undefined state. That's understandable,
>but what if my oneshot script was carefully written and handles signals
>correctly and always leaves system in a predictable state and can be
>started multiple times (ie. it is idempotent)?
If you're confident in your script, then you can obviously do whatever
you want 🙂 "Don't interrupt oneshot services" is a guideline, not an
absolute rule.
>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.
>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.
--
Laurent
Received on Wed May 13 2026 - 20:27:21 CEST