Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no place for packages to drop oneshot boot/shutdown tasks #23

Closed
CameronNemo opened this issue Jul 11, 2019 · 10 comments
Closed

no place for packages to drop oneshot boot/shutdown tasks #23

CameronNemo opened this issue Jul 11, 2019 · 10 comments

Comments

@CameronNemo
Copy link
Contributor

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?

@Vaelatern
Copy link
Member

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.

@CameronNemo
Copy link
Contributor Author

Yea that is what stage 3 is haha.

Regarding where to invoke from, why nest inside rc.local and rc.shutdown, respectively?

@CameronNemo
Copy link
Contributor Author

CameronNemo commented Jul 11, 2019

According to void-linux/void-packages#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, void-linux/void-packages#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>/start action to take when task is started
  • /etc/tasks/<task>/stop action to take when task is stopped
  • /etc/tasks/<task>/onboot flag file indicating the task should be automatically started at boot
  • /etc/tasks/<task>/noshutdown flag file indicating task need not be stopped on shutdown
  • /etc/tasks/<task>/status action for custom state detection of the task
  • /run/tasks/ directory containing task state directories
  • /run/tasks/<task>/ directory for task state
  • /run/tasks/<task>/active flag 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.

@Vaelatern
Copy link
Member

Vaelatern commented Jul 11, 2019

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.

@Duncaen
Copy link
Member

Duncaen commented Jul 11, 2019

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.

@abenson
Copy link
Contributor

abenson commented Jul 11, 2019

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.

@CameronNemo
Copy link
Contributor Author

CameronNemo commented Jul 11, 2019

@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?

abenson added a commit to abenson/void-runit that referenced this issue Oct 3, 2019
abenson added a commit to abenson/void-runit that referenced this issue Oct 3, 2019
@the-maldridge
Copy link
Member

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.

@classabbyamp
Copy link
Member

classabbyamp commented Apr 13, 2023

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

@abenson
Copy link
Contributor

abenson commented Apr 13, 2023

I think so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants