void-runit
void-runit copied to clipboard
void-linux
no place for packages to drop oneshot boot/shutdown tasks
We honor rc.local and rc.shutdown, but these scripts are not accessible for packages to hook into. I propose adding rc.local.d and a corresponding shutdown directory to accommodate these use cases. Comments?
Does runit even allow executing a script at shutdown? Otherwise, it seems like a reasonable idea, so long as rc.local.d gets run from rc.local.
Yea that is what stage 3 is haha.
Regarding where to invoke from, why nest inside rc.local and rc.shutdown, respectively?
According to https://github.com/void-linux/void-packages/pull/12974, there is interest in having the boot and shutdown tasks/scripts to be coupled into a directory like the run/finish files are for services. So my local/shutdown idea needs work. There is also interest in being able to enable and disable the tasks. The directories /etc/oneshot and /var/oneshot were suggested, but I would rather not have yet another top level /var subdirectory fwiw.
Furthermore, https://github.com/void-linux/void-packages/pull/4053 demonstrates there is interest in being able to manually run the tasks during system operation.
My proposal:
-
/etc/tasks/directory containing task configuration directories -
/etc/tasks/<task>/directory for task configuration -
/etc/tasks/<task>/startaction to take when task is started -
/etc/tasks/<task>/stopaction to take when task is stopped -
/etc/tasks/<task>/onbootflag file indicating the task should be automatically started at boot -
/etc/tasks/<task>/noshutdownflag file indicating task need not be stopped on shutdown -
/etc/tasks/<task>/statusaction for custom state detection of the task -
/run/tasks/directory containing task state directories -
/run/tasks/<task>/directory for task state -
/run/tasks/<task>/activeflag file indicating the task start action has completed
A command (e.g. tasks) will be provided to interact with these tasks, similar to sv for services. The subcommands will include: list, start, stop, restart, status. Available flags will include: --onboot, --noboot, --onshutdown, --noshutdown, --active, --inactive, --verbose, --quiet, and ~~--earnest~~. The positional argument for each subcommand will be a glob pattern matching tasks that should be operated on.
~~When the --earnest flag is passed, the command will remember all tasks that fail their action. The command will make repeated attempts to invoke the action for these tasks until the list of failed tasks matches a previous iteration, or reaches zero. The former case will protect against loops or other unrecoverable situations. The purpose of this flag is to allow tasks to order themselves after one another by calling tasks --quiet status <task>, thus failing and being re-queued when the ordering is broken.~~
In stage two, the command will be invoked as tasks --inactive --onboot start '*'. In stage three, the command will be invoked as tasks --active --onshutdown stop '*'.
And after typing all this I question if I should just learn s6-rc.
Edit: remove --earnest flag from proposal. we are not trying to create a new RC system.
The problem is all this basically can be implemented with runit with exec pause and finish, unless we need to have whatever it is start before network comes up.
I am not interested in complicated and unique solutions to small problems like the above.
No exec pause is bad and should go, especially for things like nftables/iptables.
The proposed system is too complex, this looks like a reinvented rc system.
Something like /etc/runit/core-services for shutdown scripts should be enough.
Could do something stupid simple, three directories/etc/oneshot/earlyboot, /etc/oneshot/lateboot, and /etc/oneshot/shutdown. and run the scripts there if +x'd. earlyboot would be before runit services are started, lateboot could be run last (like rc.local traditionally is) and shutdown of course on shutdown.
@Duncaen how do you propose handling enable/disable? the apparmor core-service is an example of how it should not be done, from my perspective.
And what about manual restarting that leah brought up?
I agree with duncaen that it looks like you've just designed an init system, and we already have one of those. I think the problem of manually running one-shot tasks is perhaps beyond the scope of the current problems, as its looking for tooling to basically call shell scripts.
We have those already; they're called shells.
The goal here, as far as I'm aware, is to provide a machine hook in point for packages to add tasks they need early in startup or shutdown. They don't necessarily need to do it automatically, it could happen with a symlink like we do with runit, but it shouldn't be any more complicated than that.
Is this solved by the combination of core-services for startup and shutdown.d (#92) for shutdown?
There are already several packages (runit-{iptables,kdump,nftables,void-apparmor}, screen) that use core-services for startup oneshots
