On Sat, 15 Apr 2017 19:12:31 +0200
marc <marc...@welz.org.za> wrote:
> I appreciate that Steve likes the daemontools approach where the
> server process stays in the foreground, and I have no quarrel with
> the advice of including a -f foreground option... The daemontools
> approach makes a completely different set of tradeoffs - some
> people really like them, others consider them to be the lunatic
> fringe. To each their own.
>
> But for a classic sysvinit startup path, the above logic
> will do a decent job of signalling that a process is ready to
> serve requests. And has been an appropriate mechanism for
> decades. No need for yet another API.
I'll admit this: For the person not wanting to use either a
daemontools-inspired process supervisor, nor systemd (which I
understand has the same capability as daemontools to background a
foreground process), the fork-early, parent blocks, kid does the work,
kid messages (and in this case the message is just closing the pipe),
parent unblocks and exits is an excellent dependency tool, assuming all
daemons do it, do it right, and do it accurately.
About my characterizations: "Baroque" is a relative thing. What I wrote
was based on "why would you not simply use a process supervisor like
systemd?" If a person has a reason not to use such a supervisor, and in
fact the whole OpenRC init system seems to be based on such objections
to supervisors, then the six system call solution you outline
transitions from "a whole bunch of needless stuff" to "hey, that's a
pretty darn kool solution." So your solution is baroque only so far as
one enjoys using daemontools or similar.
LOL, as far as subtle, I'm just not seeing subtle in your solution. The
implementation is elegant, but is the solution subtle? Not in my
opinion. Then again, I don't think any software I ever wrote was subtle.
I have some technical questions about your software, but that's for
another email.
SteveT
Steve Litt
April 2017 featured book: Troubleshooting Techniques
of the Successful Technologist
http://www.troubleshooters.com/techniques
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
