Henrique de Moraes Holschuh <h...@debian.org> writes: > Services being subject to a package update can be down for extended > amounts of time (think package update that requires manual intervention, > or even a full manual reconfiguration, etc), or may actually involve an > ABI break. In both cases, you want that socket down.
Why? Most upgrades will *not* be down for an extended period of time, so keeping the socket up is the right decision most of the time. And if it is unexpectedly down for an extended period, the socket buffer will fill up, and then the behavior will be roughly equivalent to if you'd taken the socket down once the listen queue fills, wouldn't it? It seems to me like you get basically the behavior that you want if you leave the socket up and buffering. But maybe I'm missing something? > And you likely want it to have a configurable timeout that brings the > socket down when the service is not "allowed to reactivate" within that > timeout. Maybe it is even already implemented like that in systemd. Why not just let the kernel do this for you? > Please fix the immediate problem first, and come up with a patch to > disable the socket on "invoke-rc.d stop". If that was an attempt to ask someone nicely to assist you with something that you think is important, you missed. You have made your understanding of the problem and your belief about the correct solution manifestly clear in this bug already. I don't think anyone has any doubts about what you think should happen. However, it turns out that I don't work for you, nor do the systemd maintainers, so you might want to try for a tone more appropriate for interacting with professional colleagues than a tone appropriate for ordering around your subordinates. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx5u1zhs....@windlord.stanford.edu
