Laurent Bercot <ska-de...@skarnet.org> writes: > On 06/08/2015 11:45, tilt! wrote: >> Thing is, init scripts tend to have problems managing services >> that do not offer sufficient commandline interfaces as described >> above > > There's a simple reason for that: "init scripts" aren't > "managing services". They can more or less start and stop them, > that's about it - and they're not even doing the starting and > the stopping right. > > - Starting ? Sure, it's easy to start a service: run the stuff, and if > it's a daemon, just fork it. Right ? Wrong. When you just spawn the > stuff from your shell, it runs with your shell's environment (open fds, > variables, terminals, so many parameters that are *difficult* to clean > up and really harden). But when you spawn the stuff at boot time, it > runs with the very different environment provided by init. I can't > count how many problem reports I've read in support mailing-lists that > were really hard to track down, but in the end it was just a config > issue because the daemon launching script did not properly sanitize > all its environment, so it didn't give the same results when run by > the admin or when auto-run at boot time.
That's all nice and dandy but it all boils down to 'the code executed by the init script was deficient in some way'. [...] > And then you have the other functionality. Restarting, sometimes, > can be lighter than stop + start: maybe there's a whole lot of > config you don't have to do when you're just restarting a daemon - > for instance, if "restart" means "read your config file again", > some daemons support the convention that receiving a SIGHUP should > make them do just that. So "restart" should simply send a SIGHUP > to those, but do stop + start on the others. But that's something different. Using inetd as simple, well-known example, if I just changed /etc/inetd.conf, I want to daemon to reread it and reconfigure itself accordingly to avoid interrupting unrelated services but in case its on rampage in an endless loop, I want to get rid of the current process and start a new instance. 'SIGHUP' is just a random convention dating back to the times when signals where the only kind of IPC supported by UNIX(*) and the signal was basically hijacked because a 'daemon process' shouldn't ever receive it for some other reason. It's not universally supported and not all daemons are so simple that "reread the config file" is the only means of controlling them at run time. Eg, someone might want to ask bind to reload a specific zone. Runtime control of a long running process is a task dependent job. And since init scripts are task-agnostic, they cannot (sensibly) provide it. [...] > Init scripts just don't cut it, no matter where they come from, no > matter how simple they are or how complex they are. [...] > What is needed is a *service manager*, a real, full-fledged thing > that doesn't only start and stop services, but does it properly, > without hacks, with the same environment every time, and can tell > you whether a service is alive or not, ready or not, and gives you > a unified interface to interact with it in a simple way. (You still > have to use daemon-specific interfaces for the more complex ways, > because no service manager can unify that.) Service management is a more complex task than [nohup] /usr/sbin/ochsenfrosch >>log 2>&1 & (although this already gets one rather far) and moreover, it's comprised of both generic and task-specific jobs and it's sensible to decouple these two: Let the applications process deal with its problems and handle the generic issues with other code. Further, the runlevel/ init script mechanisms and conventions address only a part of the generic problems services management involves. But "X can't be used" is not something which follows from "I need feature beyond those provided by X". >> what does SystemD do to address this problem? > > It does exactly that. Among the myriad of useless things that systemd > does, it does at least one useful thing: it's a proper *service > manager*. Is it? Or is it an extremely incomplete, ad hoc designed programming language with a service manager and a truckload of other potentially useful stuff attached to it in order to encourage people to swallow the language? [...] > Winning against systemd involves providing better designed > alternatives to the useful parts of what it does, and service > management is one of those: there is a qualitative jump to do here, > and messing around with init scripts is only a quantitative jump and > unfortunately isn't going to accomplish anything if not paired with a > serious redesign of how booting a machine should be done. 'Winning' against systemd will require getting support of a commerically more potent company than RedHat and SuSE combined and one willing to sink a sizable amount of money into the task. And that's only a part of the solution because you'll also have to be on the lookout for senior developers whose surnames match [psk][hoi], otherwise, you might just end up getting the same thing with a different kind of lipstick put onto its face. But 'booting the machine' is a much simpler task and it can be solved within the existing framework by incrementally adding the missing bits. Over time, this may end up replacing all of it (while I maintain a sysvinit fork because that was the path of least resistance for getting some features I needed, I could easily miss a sizable part of the inherited code, although actually getting rid of it isn't worth the effort right now), however, this remains to be seen: Starting from the presumption that this will turn out to be necessary is a guess. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng