Bug 30595

Summary: Dangling socket when *.socket unit is stopped
Product: systemd Reporter: Michael Biebl <mbiebl>
Component: generalAssignee: Lennart Poettering <lennart>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Michael Biebl 2010-10-04 07:27:40 UTC 
A socket that was created by foo.socket unit is not removed when this unit is stopped.

As a real world example, you can take dbus and rsyslog.
Starting those services via socket activation, then stopping the services and *aftwards* stopping the socket units (systemctl stop rsyslog.socket) will leave the sockets /dev/log and /var/run/dbus/system_bus_socket around.
This is bad, as client applications will then try to connect to those service even if they are not running.

Of course, stopping a *.socket unit while the underlying service is still active, must not result in the socket being removed.
This should be simple by checking which applications is holding the file descriptor.

On shutdown, (systemd) services that were activated via socket activation, should not simply skip unlinking the socket, but first check, if the corresponding *.socket unit is still running. I'd say we need some API (like sd_listen_fds) for that so services can query systemd. This is arguably a separate bug report though.
Comment 1 Lennart Poettering 2010-10-14 08:38:34 UTC 
As discussed on IRC: I do believe deleting sockets earlier than necessary is the wrong approach since due to socket passing we never know when the socket is really unused.

Or to say this differently: if this is simply about the difference between the error codes of ECONNREFUSED and ENOENT on connect() then I think the disadvantages of unlinking the sockets arealy outweigh the advantages.

In fact I would actually even go further: we probably should replace existing sockets atomically by using rename() instead the simple bind() → unlink() → bind() again logic we currently use. That way, sockets stay in the file system 

Anyway, closing...

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.