Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
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 signature.asc Description: PGP signature
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
Hi, On Mon, Aug 19, 2019 at 09:55:22PM +0300, Andrei POPESCU wrote: > > I hope we also support the case where we ship a restricted unit file for > > non-systemd and a unrestricted unit file for systemd. > Would there be cases where the "restricted" unit file is using options > not present in the "unrestricted" unit file, and if yes, is that case > worth supporting? TBH, I'd expect these to diverge quickly, because in the SysV world, daemons first set up stuff they need privileges for, then drop the privileges and go into the main loop. In order to move the "dropping privileges" part into systemd, the initial set up must be part of systemd as well. This already works for sockets, which can be passed as file descriptors easily, but will be a lot more difficult for configuration files (in case the service is supposed to run in a chroot) or key material for SSL, so if people actually want to use systemd to manage privileges, they will need to add appropriate interfaces that allow an otherwise isolated service to perform privileged actions during a well-defined time period at startup, ending with the time the service reports itself as running. This only makes sense if the access control for this interface is finer-grained than what the kernel provides, otherwise we're no better off than before, so there'd have to be appropriate parameters to configure that access control. I also fully expect DLL-based services to pop up rather sooner than later, because seccomp or syscall filters cannot be set up as tightly as needed before an execve(). These will probably extend unit file syntax quite a bit as well. All of these extensions aren't useful for daemons that set up their execution environment themselves, but some daemons expect to be called in a restricted environment already, and we need to be able to distinguish that. Last but not least: We currently do not have a normative definition of an "unrestricted" unit file. I'd be very unhappy if we adopted a "restricted" definition into Debian Policy without also defining the "unrestricted" set at the same time, otherwise "unrestricted" becomes short for "unrestricted by Debian Policy". > It seems to me like a unit file to SysV translator should just ignore > the options it doesn't support, so it wouldn't be necessary to have two > different unit files. Init scripts fail when they encounter an unknown command. A useful replacement should do the same. Simon
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
On Lu, 19 aug 19, 11:55:13, Sam Hartman wrote: > > I hope we also support the case where we ship a restricted unit file for > non-systemd and a unrestricted unit file for systemd. Would there be cases where the "restricted" unit file is using options not present in the "unrestricted" unit file, and if yes, is that case worth supporting? It seems to me like a unit file to SysV translator should just ignore the options it doesn't support, so it wouldn't be necessary to have two different unit files. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
> "Enrico" == Enrico Zini writes: 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. 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. Thanks for working on driving this idea forward; it seems like a really good one.
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
Hi, On Thu, Aug 15, 2019 at 02:49:32PM +0200, Vincent Bernat wrote: > > So we might have to invent magic comments still and/or convinve systemd > > people that it might be a good idea to have unit files that can support > > both immediate and on-demand start. > It's already the case. Require the socket for on-demand start, require > the service for immediate start. Hmm, if we can just unconditionally start a service even if there is no incoming connection, then we can just do that from start-stop-daemon with a small extension. That wouldn't work for Accept=true, though. Simon
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
❦ 15 août 2019 14:11 +02, Simon Richter : > So we might have to invent magic comments still and/or convinve systemd > people that it might be a good idea to have unit files that can support > both immediate and on-demand start. It's already the case. Require the socket for on-demand start, require the service for immediate start. -- I do desire we may be better strangers. -- William Shakespeare, "As You Like It" signature.asc Description: PGP signature
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
Hi, On Thu, Aug 15, 2019 at 10:40:22AM +0200, Enrico Zini wrote: > [changed subject because I can't stand the old one] Good idea. > Alternatively, we can decide on a subset of unit files that would cover > the normal start-stop-daemon features, and like 80% of initscripts, and > would be very unlikely to be changed anytime soon by systemd upstream, > and decide that if that's all you need for your /etc/init.d script, you > can just ship the unit file and delegate the sysvinit case to the > start-stop-daemon equivalent. This will be difficult for services that in the systemd world are demand-activated to avoid having to specify their dependencies. I am fairly sure that most people using sysvinit still want to start up services immediately on boot, which unit files for demand-activated services don't even describe how to do. So we might have to invent magic comments still and/or convinve systemd people that it might be a good idea to have unit files that can support both immediate and on-demand start. > Those packages that use more unit file features can still ship an init.d > script, but at least all those packages that just start/stop a service > don't need to bother about maintaining yet another shellscript that > bitrots dangerously over time. I doubt people really use more unit file features, at least not for user space services (where the systemd and sysvinit worlds overlap), so that shouldn't be much of an issue. I still expect some init scripts to stick around for cases where unit files are not expressive enough, and I expect that to get worse when systemd actually gets a versioned API. > I even have a python implementation of most such unit file features that > I can offer as a starting point, please give me a few days[1] to talk to > one of my customers about putting it into a public git repo. I'd still be in favour of adding this to start-stop-daemon, because all that needs is an unit file parser in addition to its command line parser (which is already complex). Helpers for socket and dbus activation would also be possible, but I'm not convinced this is actually what people want. Simon
