Is it intentional that systemd holds a reference to a socket it has just accepted even though it just handed the open socket over to a socket.activated service that it has just started.
For example given the following unit files: /etc/systemd/system/test.socket: [Unit] Description=test service [Socket] ListenStream=804 Accept=yes [Install] WantedBy=sockets.target ------------------ /etc/systemd/system/[email protected]: [Unit] Description=test per-service unit [Service] ExecStart=-/home/ben/Work/sysdtest/sysdtest ------------------ The sysdtest is just a program which essentially daemonizes itself and then sleeps for a few seconds. So it doesn’t have an open reference to the file descriptor that was accepted. Yet the socket stays open and connected to the client until the daemon like process exits or the timeout for the service instance is reached because systemd holds onto a reference to the file descriptor. Is this intentional? The behavior differs from xinetd which didn’t hold onto any references to the newly accepted socket. This allowed the socket to close as soon as the socket activated process daemonized. Holding onto a reference to the socket FD surprised me enough that I verified that it was in fact systemd holding the reference by using lsof: [ben@localhost sysdtest]$ sudo lsof -i :804 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 19u IPv6 384026 0t0 TCP localhost.localdomain:804->localhost.localdomain:46220 (ESTABLISHED) systemd 1 root 30u IPv6 376208 0t0 TCP *:804 (LISTEN) telnet 1021 ben 3u IPv4 384025 0t0 TCP localhost.localdomain:46220->localhost.localdomain:804 (ESTABLISHED) -ben _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
