> On 12/06/2015 22:21, marcxdv@??? wrote:
> >The trick is for the daemon process to only background when
> >it is ready to service requests (ie its parent process exits
> >when the child is ready).
>
> You already mentioned it in a reply to me, indeed. I intentionally
> did not follow up, and here is why.
>
> This is bad design, for several reasons. It's actually worse design
> than sd_notify(), and I'd rather have every daemon use sd_notify()
> and write a sd_notify server myself than recommend your solution.
>
> The reasons why it's bad are mostly described here:
> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html

It is only bad design if you have your heart set on a supervision
framework like daemontools. Such frameworks have been around
for decades too, and have not caught on (also for several reasons ;)
The above link even lists all these attempts, and so presumably
has the agenda of trying to make these frameworks happen

The biggest reason is that in a number of applications it is unclear
if and when things should turn in to a daemon. Consider something
like screen - things only background when you press <control-A d>. In
general terms having a supervision framework means that a daemon is
something an administrator decides to create, not something which the
user asks his application to become.

This has at least four undesirable side-effects:

* It becomes harder for end users to run their own daemons. Harder,
less convenient, whatever. Not impossible - with enough contortions
anything is possible. But it disempowers non-admin users.

* Daemon programmers get to become lazy - where previously a crash
was something horrible, a crash now means that the supervision
framework restarts it, so no biggie. Welcome to windows, where
software is expected to crash

* People are lulled into the false sense of security: "My supervision
framework thinks the process is still up, so things are ok". But
your process has has been running in an infinite loop for the
last couple of days. If you want to have monitoring, monitor
your task at the service it provides (retrieve a web page from
a web server, finger the finger daemon). Inevitably that requires
domain knowledge, which supervision framework advocates struggle
to realise. Or if you are Lennart, you end up absorbing all domains
into your supervision framework, at which point we have to
fork a distribution

* Supervison frameworks are marketed as "So easy to use, any idiot
can write a daemon". And assume it to be true and every idiot writes a
daemon. People who don't know what an attack surface is, how a
protection domain gets synthesised, etc. And typically in languages
which assume infinite RAM and CPU time, cause if they run out, they
just hit the wall...

> Your solution enforces forking, i.e. auto-backgrounding, and
> prevents logging to stderr; in doing so, it prevents daemons from
> ever being used with a supervision framework.

Closing stderr to the parent does not prevent logging to stderr, you can
quite happily close a file descriptor with dup2(). Or you could use
some other logging framework, but that would then conflict with the
supervision framework. Framework collisions

On a personal note: You have been making a number of pronouncements
which suggest incomplete understanding of unix: Here unaware of dup2(),
but in previous posts you were unclear on when a shell needs to do a
stat() (5542B2D4.5030208@???), misunderstood security through
obscurity (55449253.902@???), do not realise that a setgid
exectuable which isn't world executable is almost useless
(5545E741.5000900@???)

So in general this ok, everybody starts off new, nobody is perfect, etc.
But surely it is worth understanding something before wanting to
redesign it wholesale (5542603E.8000303@???, and now here
with daemon startup). Especially in a forum (devuan) which appears
to have been forked in response to such a poorly conceived redesign.
Consider your closing statement here:

> But auto-backgrounding is not good
> design in the first place; it comes from ancient Unix times when we
> did not know better, and the daemon() function should either
> disappear into oblivion, or have a place in the museum of medieval
> programming as an example of how not to write Unix software.

This paragraph does not convey anything useful, and the tone
comes across as arrogant - consider carefully whom label as not
knowing how to write Unix software, cause you might fit that
description rather well, like all of us

regards

marc