Laurent Bercot:
> Jonathan de Boyne Pollard:
>> Application X, whose rate of continual DNS lookups is why there's a
>> local dnscache in the first place, needs as close to uninterrrupted
>> DNS service as it can get, even in the face of system administrators
>> who know that "we can just clear that problem out of the local cache
>> and get things fixed today by killing the DNS server and letting it
>> auto-restart, can't we?" and then terminate the service twice.
>
> Sysadmins *should* be able to make that assumption, and even if the
> restart is delayed by one second [...] they should never hesitate to
> go for the easy fix.
Actually, no; and I speak as someone who has said exactly that. (I've
probably written "svc -t /service/dnscache" a couple of times on the
djbdns mailing list in years gone by.)
It's an assumption that works in the daemontools family world, but it's
an assumption based upon the likes of you, I, M. Pape, M. Marshall, M.
Guenter, and M. Bernstein making an assumption ourselves. We have
actually made a design decision that needs to be recognized: that in our
systems the design of the service manager is in the default case to
always auto-restart daemon processes. It's this design decision, that
can be traced all of the way back to the behaviour of init, that leads
to the user knowledge that sending a SIGTERM is a way to trigger a
graceful restart, as exemplified on scads of perp/runit/s6/daemontools
"Here's how I use it" WWW sites. (Random example:
http://isotope11.com/blog/manage-your-services-with-daemontools) It's
this design decision that leads to "systemctl condrestart" translating
to "svc -t".
But it's not the only design decision in town. The systemd design
decision, exemplified by
https://fedorahosted.org/fpc/ticket/191 amongst
several others, is that a user sending a SIGTERM to a daemon is
operating under System 5 rc assumptions, where that signal is a way to
stop a service, not to restart it. "systemctl condrestart" is actually
more complex in systemd. You talk of not people exercising brain power,
whilst missing the fact that in that case people don't operate under the
assumptions that you designed for. I still get to explain to people to
their surprise that yes, if you terminate the process another instance
of the program is automatically started, so I am still reminded of this
difference in thinking. (-:
An encoding of that difference: Whilst people are encouraged to use
Restart=on-abort or Restart=on-failure by systemd people, nosh is on the
daemontools family side of the fence and has the equivalent of
Restart=always for many service bundles. I was right about how quickly
interest in System 5 rc scripts would wane. I suspect that I'm going to
be right about how quickly people learn "systemctl start" and "systemctl
stop" in place of the very System 5 habits being catered-to here. (It
helps in making this educated guess to see how quick they already were
to learn "service X start", "initctl start", "service X stop", and
"initctl stop".) The systemd people are probably erring too far on the
side of caution, here.
Received on Mon Jun 08 2015 - 18:22:06 UTC