init issueshttps://gitlab.redox-os.org/redox-os/init/-/issues2019-01-31T04:37:56Zhttps://gitlab.redox-os.org/redox-os/init/-/issues/2Child Daemonization2019-01-31T04:37:56ZSamwiseFilmoremggmugginsmc@gmail.comChild DaemonizationBased on my understanding of process supervision and [systemd's docs](http://0pointer.de/public/systemd-man/daemon.html#New-Style%20Daemons), daemons that are managed by `init` (which should be all of them) should not fork off and effect...Based on my understanding of process supervision and [systemd's docs](http://0pointer.de/public/systemd-man/daemon.html#New-Style%20Daemons), daemons that are managed by `init` (which should be all of them) should not fork off and effectively daemonize themselves, rather, they should continue to run in the foreground and let their calling process handle daemonizing. Fixing this requires a couple of things:
- [ ] `init` should assume that a service's `methods.start` is a process which runs as a daemon. Also add an option in the service file which can override this, for scripts that run startup tasks, etc.
- [ ] Better service state management
- [ ] Many MR's to many redox repos (the ones that provide daemonized services) in order to
- [ ] Make daemonization opt-outable via an argument (later changed to opt-in/removed after the rewrite is the default)
- [ ] Put service configuration files either in cookbook or in the service's repository (not strictly related but can be bundled with this issue)Ship Rewrite as DefaultSamwiseFilmoremggmugginsmc@gmail.comSamwiseFilmoremggmugginsmc@gmail.comhttps://gitlab.redox-os.org/redox-os/init/-/issues/3Decide on Immediately Relevant Config Options2019-01-31T04:53:31ZSamwiseFilmoremggmugginsmc@gmail.comDecide on Immediately Relevant Config OptionsService configurations currently support cool things like multiple methods, dependencies and provides, environment variables, user and group configuration, and setting redox namespaces. However, there are a couple of corner cases that ha...Service configurations currently support cool things like multiple methods, dependencies and provides, environment variables, user and group configuration, and setting redox namespaces. However, there are a couple of corner cases that have proved more difficult for me to fit into the service configuration file model.
Right now, init's flow looks something like this:
- Initialize logger and the state/metadata graph
- Parse service files from `initfs:/`, add them to the graph, and start them all
- Switch stdio from `debug:` (kernel provided) to `display:1` (the screen, provided by one of the services on `initfs:/`)
- Parse service files from `file:/` (provided by another service from `initfs:/`, `redoxfs`), add them to the graph, and start them all
- Drop into the null namespace and `waitpid(0, 0)`
I mean, this works really pretty well for the standard setup, but its warrants get less flexible as we go down the list:
- Some service on `initfs:/` provides `file:`, and there are services there which _should_ be started
- Some service on `initfs:/` provides 'display:`, and we _should_ switch our output to it
- No more services are going to be added during the lifetime of init
- Services do not need to be checked later and reincarnated if they fail
That third one is particularly sticky, and the fourth is directly contradictory to one of the stated goals of this rewrite. Theoretically, one could install a package that provides a service and want to be able to start it after installing it. However, if init is in the null namespace, it is no longer capable of opening files. That's an easy fix, but the dependency and service starting system are also not nearly robust enough to handle dynamically inserted services which must be brought up, nor are they adequate for dealing with a service failure that requires reincarnation. These are all implementation details, and my plan is to implement some kind of event system internally, which should result in a more flexible state/metadata graph.
The reason I opened this issue is to address how to integrate "special" things, like realizing that services in `file:/` should be parsed, or that init's stdio streams should be piped to `display:1`. I feel like all that stuff should be defined at runtime, but I'm not sure how it fits into the service file model. On this I'd like suggestions. If you'd like to become more familiar with the service configuration file syntax, an example service with many comments can be found in the [examples/](https://gitlab.redox-os.org/redox-os/init/blob/dependencies/examples/example_service.toml) directory. Hopefully that's helpful.Ship Rewrite as DefaultSamwiseFilmoremggmugginsmc@gmail.comSamwiseFilmoremggmugginsmc@gmail.com