On Thu, Aug 06, 2015 at 02:21:55PM +0200, Laurent Bercot wrote: > 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.
If differences in environment can cause problems, it's a problem with design. A program that changes what it does just due to differences between the init environment and a login environment is going to be hard to debug. Also, if I'm reading this right, you're implying that execline does clearenv(), sets a new environment, and also closes all fds above 2. > - Stopping ? Sure, just find a daemon's pid... oh wait, we need to > have it stored somewhere. Hence, .pid files. If you don't know why > .pid files are evil, look it up. It took me ... less than a minute to find "pgrep -F". That solves the problem of stale pidfiles. > 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. That's confusing. > There's the "reload" keyword sometimes, but are there any precise > semantics ? restart means start and stop. reload means reread config file. > And "status". This is very service-dependent: since there is no > global API, no service manager, scripts will query the daemon's > status in a daemon-specific way. More vagueness again, because > "status" doesn't define exactly what you should say, and the lowest > common denominator is "is it alive?" but even for this basic check, > daemon-specific interfaces are used. The status command was originally "is it running?", but yes, that's barely useful. If you use a pidfile and pgrep -F, that would work. Using a tool dedicated to the purpose is more helpful than any service manager can be (unless your service manager is a hundred-megabyte hog). Think it's hung? strace/ltrace the pid. Wondering what files it has open? Use lsof or look in /proc/$PID/fd/. ... Thanks, Isaac Dunham _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
