[Pkg-systemd-maintainers] Bug#738207: Bug#738207: systemd-sysv: sockets are not removed after being stopped

[Andreas Cadhalpun]

Hi Michael,

On 08.02.2014 22:26, Michael Stapelberg wrote:
> Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> writes:
>> Stopping a systemd socket does not remove the socket file, e.g. after
>> sudo systemctl stop avahi-daemon.socket
>> the socket file /run/avahi-daemon/socket remains.
>>
>> This is not the expected behavior, because if the socket file exists,
>> other programs usually assume that it is listened on.
> This has been discussed upstream already:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=30498#c4
> http://bugzilla.adiscon.com/show_bug.cgi?id=200#c6
>
> Therefore closing this bugreport.

If this is considered correct, then at least the man page is wrong, 
because 'man systemd.socket' says, as Josh Triplett pointed out to me:
ExecStopPre=, ExecStopPost=
     Additional commands that are executed before or after the listening
     sockets/FIFOs are closed and removed, respectively. Multiple
     command lines may be specified following the same scheme as
     used or ExecStartPre= of service unit files.

The formulation 'closed and removed' makes it clear, that the sockets 
should get removed, when they are closed.
So at least this needs to be changed, possibly by just removing the 'and 
removed'.
Would you please reopen the bug for this?

> Note that if you want to get features/behavior changed, please directly
> talk to upstream. We are maintaining the Debian packaging of systemd,
> and we don’t want to introduce such changes without upstream agreeing
> with it.

I always tend to think that reporting a bug in Debian should be done 
first, as it is possible that the bug is Debian specific, particularly 
if the Debian version of the package is not the current upstream 
version. If this is not the case, it is easy enough to forward it to an 
upstream bug.

Now the upstream argumentation you referenced is:
Michael Biebl:
"I had a short discussion with Lennart on irc. His position is, that the 
socket, once created by systemd, should stay around, always. Even if the 
service, listening on this socket and the corresponding socket unit are 
down.
In such a case an application/client would get ECONNREFUSED instead of 
ENOENT."

Lennart Poettering:
"Which question precisely? A stale socket should be fine.

I think the only remotely race-free way to handle all of this is to 
delete the socket in the last possible moment, i.e. right before 
creating a new one. Ideally we'd even make this atomically, which we 
probably could do with renaming or so..."

So it seems there would be some problems with race conditions, if the 
sockets were removed, but I don't see what kind of problems that would 
be. Could you explain this?

 From my limited point of view, not removing the socket has negative 
side effects:
  * Detection of ECONNREFUSED is harder then to detect if a socket file 
exists or not, particularly if one only uses the socket indirectly by 
calling a command line program and has to rely on the error handling of 
that.
  * When using sysvinit, the daemon creates the socket upon starting and 
thus removes it upon closing. The only case where the socket could be 
left open, if the service is not running, is, when the service crashed. 
So systemd not closing sockets leads to a similar outcome as a crash 
under sysvinit, which is confusing at least.

Best regards,
Andreas