Daniel Campbell posted on Tue, 09 Feb 2016 06:44:34 -0800 as excerpted: > If anything, a developer will have more control over how their daemon > is handled in the rc script. They would have to read systemd's C code > or its plethora of unit options to set it up 'just right' to achieve > the same.
FWIW, that's an unfortunately common misconception. It's just as easy to setup a shell script to do the work in systemd as it is in rc-based systems. After all, at a high level it's simply another executable, and at an equally high level, setting up executables to run automatically at system start or other major system status change event is what init systems, regardless of the specifics, /do/. And in fact, that's pretty much what I've done here for a variety of custom services, using native systemd options and functionality where it makes sense, scripting my own where I haven't found shipped functionality or services that do exactly what I want. And I don't claim to be a C coder so I've certainly not had to read that to do it. While I've used systemd unit options where they make sense because they're generally well documented and do what it says on the tin, if I'd considered rescripting that functionality easier than reading the friendly documentation, I certainly could have done so. Meanwhile, arguably, "more control over how their daemon is handled" is incorrect as well, when with systemd it's trivial to setup cgroup control over anything cgroups control, and there's tools like nspawn if needed, that allow _way_ more control than chroot and the like, with similar levels of pre-configuration necessary. But that's beside the point of the original thread. I disagree with Rich here, because while (like him) I'm a systemd convert myself, I'm strongly in support of keeping it optional, and on profiles where systemd isn't the default, it simply makes no sense to me to default to a device manager that strongly discourages that sort of usage and has said that future breakage is a matter of when, not if, when there's a similarly functional and currently drop-in-replacement device manager that explicitly supports the use-case in question. If it applied to systemd profiles, the question of an appropriate default and its resolution would arguably be far different, but the fact of the matter is it doesn't, we're talking about non-systemd profiles exclusively, and their default openrc use-case is strongly discouraged by udev's systemd upstream, so it simply makes sense to choose defaults where the upstreams aren't rabid enemies. My major remaining concern is, as I've already said, documentation. If that can be resolved, the case is clear enough, and even if not, it's simply a judgment call on which negative is less bad, lack of documentation, or an upstream that's actively opposing our use-case and has clearly stated that breakage is a matter of when, not if. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
