On 13/06/2015 10:43, marc wrote:
It is only bad design if you have your heart set on a supervision
framework like daemontools.
No, it is bad design because
- it lengthens the code path before the service is operational
- it requires software authors to write more code into their
daemon instead of less, code that could otherwise be factored
- it prevents system administrators from running the service as
they choose, supervised or not. Even systemd gives administrators
this choice.
Such frameworks have been around
for decades too, and have not caught on (also for several reasons ;)
Lots of good ideas have not caught on. Plan 9 has not caught on.
Itanium has not caught on. Popularity has never been a suitable
measure for technical quality, and if we were after popularity, we
would be using Microsoft Windows.
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.
Um, yes. Supervision frameworks were made to help administrators, and
usually run noninteractive programs. The way you manage a system requires
planning, as any management task.
The thing is, they don't prevent users from doing whatever they want.
If a user wants to daemonize a screen process previously running
interactively, then fine - it's possible to do so. It won't be supervised,
but who cares? It wasn't supervised in the first place and does not need to.
Also, I honestly wouldn't use GNU screen as an example of good software
design, but that's not the point.
* 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.
Huh? Non-admin users have exactly the *same* ways to run their
own daemons with or without a supervision framework. And that is the
point: it's always possible to make a program run in the background,
whereas it's much harder to make an auto-backgrounding program run
in the foreground. Supervision does not take away anything from anyone,
it *opens up* possibilities.
* 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
This is a complete straw man, akin to blaming antiretroviral treatment
for people having unsafe sex and catching AIDS saying it's not that
big of a deal anymore.
* 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).
Supervision frameworks do not replace competent system administration,
complete with logging, in-service monitoring and alerts if your SLA
requires it. They only make it easier. This is another strawman.
Inevitably that requires domain knowledge, which supervision framework
advocates struggle to realise.
Nothing replaces domain knowledge. Wanting to make administration easier
is not the same as wanting to dumb it down. Progress and convenience is
not decadence, unless you miss the time where washing machines did not
exist, and men were men and did all their laundry by hand - wait, they
didn't, they enslaved women instead.
Or if you are Lennart, you end up absorbing all domains
into your supervision framework, at which point we have to
fork a distribution
The fact that I'm following this list should make it clear that I'm not
Lennart, and about anything I've written here or anywhere else should
make it clear that my goal is quite opposite to absorbing all domains.
* Supervison frameworks are marketed as "So easy to use, any idiot
can write a daemon".
No, this is not what they are marketed as, and you are severely
misinterpreting.
Closing stderr to the parent does not prevent logging to stderr, you can
quite happily close a file descriptor with dup2().
The child is run with stderr pointing to a pipe to the parent. You
have to close that descriptor for the parent to exit. The original
stderr, the one the parent was run with, is overwritten with your
dup2() in fork_parent() and the child has no access to it; and it is
irremediably lost when the parent exits.
You can dup2() all you want in the child, you will never get the
original stderr back, which is of course the point of logging to
stderr - you want to log to the stderr the daemon has when it is
started!
Or you could use
some other logging framework, but that would then conflict with the
supervision framework. Framework collisions
You can use syslog all you want with supervision frameworks, they
will not conflict with it. Supervision frameworks are about opening
possibilities, not closing them.
On the other hand, fork_parent() conflicts with using stderr as
a logging stream.
On a personal note
This is the reason why I ignored your previous answer. I suspected
that by pointing out mistakes in the fork_parent design, I would not
elicit a technical discussion, but emotional reactions and negativity.
I made the mistake of giving in when you insisted, and I regret it.
I have given you technical arguments. You have given me nothing else
than misunderstandings of supervision frameworks, misinterpretations,
and logical fallacies; and then personal attacks. In the list you
pointed out, only the setgid thing was an honest mistake of mine,
which I admitted to; the rest were misunderstandings that got cleared
out. I attacked your design, not your person; in reply you patronized
me and called me arrogant, without a single technical point to show.
I do software design, not Internet flamewars or people management.
I have said what I had to say on the matter, and am done with this
discussion.
--
Laurent
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
