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.
That's right. In practice, it's rare that you'd want to reboot while
a concurrent state change is running. Typically, s6-rc is only running
at boot time, until the machine is in its cruising state; I think it
is acceptable to at least wait until the boot has finished before
rebooting the machine.
In case of emergency, pkill s6-rc before rebooting. It's ugly, but it
will work if you really need it.
It is something to think about. Setup is kinda complex: I have a longrun
"A" that does "s6-rc start foobar"
Is A a service run by s6-rc, in the same service database as foobar?
If it is, I would strongly advise you not to do that. Do not invoke
s6-rc commands from within a service that is managed by s6-rc: that
might deadlock or fail.
If A is run independently from s6-rc, even if it is a supervised
service
under the same scan directory (e.g. you launch it as an early service
via s6-linux-init) then there is no problem.
--
Laurent
