Discussion:
Stopping services started by Systemd socket
(too old to reply)
Liam Kelly
2018-01-23 01:06:40 UTC
Permalink
Raw Message
How does Systemd communicate to socket activated application that the connection has been closed? How can I modify my application to detect this event if it cannot be configured to be closed automatically?

We are trying to add network support to legacy code using Systemd sockets. Using the 0pointer tutorials, we were able to configure a listening TCP port and launch an instance of the application when a TCP connection came in. The problem is that when the connection is closed, the service is still running.

The systemct list-units and netstat -tuapn outputs are what you would expect when the connection is established

    systemctl list-units:
    ***@5-192.168.0.75:10001-192.168.210.102:19983.service loaded active running   My App
    netstat -tuapn:
    tcp        0      0 192.168.0.75:10001      192.168.210.102:19983   ESTABLISHED 1/init
However, once the client closes the connection, the socket is closed and removed, but the application is still running as a service:

    systemctl list-units:
    ***@5-192.168.0.75:10001-192.168.210.102:19983.service loaded active running   My App
    netstat -tuapn:
    [no entry]

-Liam Kelly
Mantas Mikulėnas
2018-01-23 07:18:41 UTC
Permalink
Raw Message
Post by Liam Kelly
How does Systemd communicate to socket activated application that the
connection has been closed? How can I modify my application to detect this
event if it cannot be configured to be closed automatically?
We are trying to add network support to legacy code using Systemd sockets.
Using the 0pointer tutorials, we were able to configure a listening TCP
port and launch an instance of the application when a TCP connection came
in. The problem is that when the connection is closed, the service is still
running.
The systemct list-units and netstat -tuapn outputs are what you would
expect when the connection is established
active running My App
tcp 0 0 192.168.0.75:10001 192.168.210.102:19983
ESTABLISHED 1/init
However, once the client closes the connection, the socket is closed and
It is no different from any other type of networked service. Whether you
opened the socket yourself, or received it from a superserver, makes no
difference.

For example, if your program uses poll(), the kernel reports POLLHUP on a
closed socket. If the program uses read() or recv(), 0 bytes indicates that
the socket is closed. If the program uses simple stdio (inetd style), it's
enough to check for EOF on reads from stdin.
--
Mantas Mikulėnas
Jérémy Rosen
2018-01-23 08:28:36 UTC
Permalink
Raw Message
that's not really an answer to your question but...

have you looked at systemd-socket-proxyd ? it's a simple program that is
meant to be started by a socket and will redirect all traffic to another
local port.

Properly used it allows a traditional network daemon to be started on
demand. I won't go in the details, it's pretty well explained in the man
page.

Depending on why you are converting your software, it could be something
interesting to look at...
Post by Mantas Mikulėnas
Post by Liam Kelly
How does Systemd communicate to socket activated application that the
connection has been closed? How can I modify my application to detect this
event if it cannot be configured to be closed automatically?
We are trying to add network support to legacy code using Systemd sockets.
Using the 0pointer tutorials, we were able to configure a listening TCP
port and launch an instance of the application when a TCP connection came
in. The problem is that when the connection is closed, the service is still
running.
The systemct list-units and netstat -tuapn outputs are what you would
expect when the connection is established
active running My App
tcp 0 0 192.168.0.75:10001 192.168.210.102:19983
ESTABLISHED 1/init
However, once the client closes the connection, the socket is closed and
It is no different from any other type of networked service. Whether you
opened the socket yourself, or received it from a superserver, makes no
difference.
For example, if your program uses poll(), the kernel reports POLLHUP on a
closed socket. If the program uses read() or recv(), 0 bytes indicates that
the socket is closed. If the program uses simple stdio (inetd style), it's
enough to check for EOF on reads from stdin.
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 AsniÚres-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email ***@smile.fr <mailto:***@smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>


Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire
Lennart Poettering
2018-01-23 17:39:16 UTC
Permalink
Raw Message
Post by Liam Kelly
How does Systemd communicate to socket activated application that
the connection has been closed? How can I modify my application to
detect this event if it cannot be configured to be closed
automatically?
systemd does not. You get the original kernel socket passed and you'll
see EOF/POLLHUP on it when the connection is terminated. systemd won't
signal anything there, and in fact it's entirely up to your app to
exit or stick around after EOF/POLLHUP.
Post by Liam Kelly
We are trying to add network support to legacy code using Systemd
sockets. Using the 0pointer tutorials, we were able to configure a
listening TCP port and launch an instance of the application when a
TCP connection came in. The problem is that when the connection is
closed, the service is still running.
Just call exit() from your app's sources as soon as you get read()
returning 0 on the socket (which is how the kernel reports EOF
in-line), or poll() returning POLLHUP on it (which is how the kernel
reports EOF out-of-line), depending on your context.

Lennart
--
Lennart Poettering, Red Hat
Loading...