On Mon, Aug 19, 2019 at 11:55:13AM -0400, Sam Hartman wrote: > Enrico> Those packages that use more unit file features can still > Enrico> ship an init.d script, but at least all those packages that > Enrico> just start/stop a service don't need to bother about > Enrico> maintaining yet another shellscript that bitrots dangerously > Enrico> over time.
Here it is: https://github.com/Truelite/python-unitd It is a python library I wrote for a customer who needed to run X clients inside a web browser. It needed extensive process management to do so, and I decided to shape the library API after systemd's primitives, so that the API's behaviour could be trivially understood. I don't think that code solves the problem at hand as it is now, but it could be a basis for a systemd-like start-stop-daemon which can use python's asyncio infrastructure for more complex process control. > I hope we also support the case where we ship a restricted unit file for > non-systemd and a unrestricted unit file for systemd. > I'm imagining a common case for me: I want to use a lot of security > isolation features some of which may not be in the restricted unit file > subset. > But my fallback would simply be to not get security isolation, and I'd > hate to have to write an init script for that. For me, that would be solved by ignoring any directive in the .unit file that the code doesn't understand. Given that we are talking of replacing trivial init.d scripts, not of reimplementing all of systemd's features in a new command, I think that would be sufficient, and the debian or upstream maintainer can take the responsibility of deciding when to shift from the trivial .unit file to a complex init.d script. An alternative idea to all this could be to write a simple "compiler" from trivial .unit files to init.d scripts. > Thanks for working on driving this idea forward; it seems like a really > good one. I've been boggling at the dangerous replication of code in /etc/init.d and in daemon startup code for most of my professional life. I personally switched to systemd and feel much better for it, and even when systemd is not there, I see great value in the standardization of daemon start/stop behaviour and expectations that came with systemd. I'm not sure I'd drive this much forward than having gotten unitd published as a possible starting point, should such a base be needed: indeed, one can also extend start-stop-daemon in that direction. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: PGP signature
