Bug#736258: acpid won't stop, won't upgrade (systemd) - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736258

[Russ Allbery]

Sorry about the delay in responding.

Henrique de Moraes Holschuh <hmh at debian.org> writes:

> Large time outs can cause bad side-efects on surprising ways.  If the
> socket is down, you get an immediate connection refused reply, which
> short-circuits the time out.

> As this is a generic feature, we could be talking about openldap, or the
> syslog daemon, or mysql, or a game server, or a DNS server...  The point
> is: we don't know.

This point and the other points in your message are well-taken.

To take a step back, I think this is a fair summary of the discussion.
Please let me know if you disagree:

1. We both agree that package maintainers should be able to choose between
   leaving the socket open while restarting the service or closing both
   the socket and the service.  In many cases, the former will be more
   appropriate and safer since no connections will be lost, but the latter
   is better for upgrades that could take some time or where connections
   shouldn't be queued for whatever reason.

2. The default behavior in Debian for many years has been to stop both the
   service and the socket.  We don't know what may be relying on this, or
   what the consequences of not stopping the socket may be for a
   particular service.  In *most* cases, in a typical fast upgrade, it's
   probably beneficial, but that may not always be the case.

3. You would prefer to start with preserving the existing behavior, and
   then add the option for package maintainers to switch to the new
   behavior of keeping the socket open if desired.  My inclination was to
   take the opposite approach since I think keeping the socket open is
   better in the common case.

4. In the absence of an implementation of the ability to choose behavior,
   you would prefer to keep the previous default of stopping both the
   service and the socket, and don't believe package maintainers are
   typically thinking about this when converting their packages to systemd
   and adding socket files.  There is some evidence to support this belief
   given the bug that started this discussion.

If that's correct, I think there are two key things that we're missing:

1. Some way for maintainers to select whether or not to stop the socket
   when using invoke-rc.d stop during an upgrade.

2. Education for package maintainers about this issue and the tradeoffs
   involved.

I feel guilty about the second, since this is exactly the sort of topic
that should be covered in Policy documentation for systemd integration,
which I had planned on working on before my day job exploded.

I think you've convinced me that the approach of stopping a socket by the
same name when stopping a service in invoke-rc.d stop (which means
starting it again with invoke-rc.d start) is the safer approach.  At this
point in the transition and release cycle, I think erring on the side of
taking the safer approach at the cost of some features is best.  I think
everyone agrees that there should be some way to control this at the
invoke-rc.d layer for package maintainers to manipulate.

This is clearly something that needs some further attention for good
integration in the longer term.

> I apologise if I sounded pushy, it was not my intention.

Thank you very much for the gracious apology.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>