Hi, On 6/25/23 23:15, Mark Hindley wrote:
The most recent proposal[6] for updating the Policy with a requirement to use tmpfiles.d(5) states
"Init systems other than ``systemd`` should allow providing the same functionality as appropriate for each system, for example managing the directories from the init script shipped by the package."
The way I see it, we are getting a split between "daemons" and "services", and it simply does not make sense to start a "service" directly from an init script, because it requires the service orchestrator as its runtime environment.
Init scripts are useful for starting daemons. If you need a service started, you need an appropriate service wrapper, and that is outside the scope of an init system. The lack of these interfaces is not a deficiency, but a deliberate design decision.
My expectation is that some daemons will gain some systemd integration, but keep the non-systemd code because it is still useful during debugging and in container environments, and init scripts would use the non-systemd invocation interface.
This creates an inconsistency whereby non-systemd inits are required to provide functionality in their initscript, but that initscript is not required to be present.
"If it is present, it also needs to work." sounds like a reasonable statement though.
Simon
