On 06/08/2015 16:31, Isaac Dunham wrote:
> 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.

There are tons of those, and you can't fix them all. Stupid example:
less. Behaves differently when its stdout is a terminal and when it's
not.
The only way to ensure reproducible behaviour for a program, no matter
what it is, is to start it in a reproducible environment.


> It took me ... less than a minute to find "pgrep -F".
> That solves the problem of stale pidfiles.

Do you think so? See for yourself:
https://gitlab.com/procps-ng/procps/blob/master/pgrep.c

It just reads the pid in the pidfile, and does its matching with
the read pid. Unless you also give other options to narrow the match,
it will have the exact same problem.
Now, of course, you can give the executable name, and add even more
guards to make sure you don't find the wrong process. At the end of
the day, you wrote a nice and complex pgrep command line, you're
*almost* 100% sure that it will nail your process and only yours,
and you just scanned /proc to send a goddamn signal to a daemon.

I'd rather type "s6-svc -d /run/service/my-daemon" and kill my
process with absolute certainty, using 10 or 20 times fewer system
calls than pgrep and a small fraction of the CPU time.


> restart means start and stop.
> reload means reread config file.

Ah, thanks.


> Using a tool dedicated to the purpose is more helpful than any service
> manager can be

For "status" ? Yes, without a doubt. I believe a "status" command
should only give the up/down state and readiness state.

--
Laurent