Hi Michael,
On 08.02.2014 22:26, Michael Stapelberg wrote:
Andreas Cadhalpun <andreas.cadhal...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
