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