Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
A customer would like to have a new option ("ClearSocket") to Socket units that would let systemd clear the content of the socket prior to listening again.
This would be useful for sockets that have Accept=no and let the service handle the socket.
Upon service stopping or dying, the customer would like that any pending data or connection get cleared, which would avoid systemd from starting the service again immediately.
ClearSocket - when set to true, the setting ensures the socket's buffers are cleared when a service fails or is stopped. The setting is applicable to services that perform their own accept(). Enabling the parameter may be a useful way to prevent restarting an Accept=false type of a service that failed before accepting socket contents, which could lead to a restart loop. While systemd's default behaviour is to expect the application to accept the data, there may be circumstances when a failure of the application controlled by the service needs to involve a reset of the socket's buffer to suppress a restart due to unconsumed socket contents. As the socket buffer is cleared, the socket is returned to the initial listening state, so new data arriving in the socket may yet again trigger the service. With ClearSocket=true is guaranteed it will not be the former contents of the buffer that started the earlier instance of the service that had failed or been stopped by the user. Defaults to false, i.e. socket's contents are not cleared following a service's spontaneous failure or a offlining.
Version-Release number of selected component (if applicable):
systemd-239 and later
Additional info:
To enable this functionality with current implementation, a solution already exists with playing with the service unit definition, but this leads to error messages in the journal, which may be confusing.
The solution consists in stopping the socket from listening in ExecStopPost of the service unit, making sure the service always fails in ExecStopPost and using "OnFailure" to start the socket again, as shown below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[Unit]
OnFailure=<myservice>.socket
[Service]
...
ExecStopPost=/bin/bash -c '/bin/echo "Stopping socket listener"; /bin/systemctl stop <myservice>.socket'
ExecStopPost=/bin/false
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
With this in place, upon service stopping/dying, the socket will be stopped then immediately restarted (thanks to OnFailure).
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: systemd security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2021:1611
Description of problem: A customer would like to have a new option ("ClearSocket") to Socket units that would let systemd clear the content of the socket prior to listening again. This would be useful for sockets that have Accept=no and let the service handle the socket. Upon service stopping or dying, the customer would like that any pending data or connection get cleared, which would avoid systemd from starting the service again immediately. ClearSocket - when set to true, the setting ensures the socket's buffers are cleared when a service fails or is stopped. The setting is applicable to services that perform their own accept(). Enabling the parameter may be a useful way to prevent restarting an Accept=false type of a service that failed before accepting socket contents, which could lead to a restart loop. While systemd's default behaviour is to expect the application to accept the data, there may be circumstances when a failure of the application controlled by the service needs to involve a reset of the socket's buffer to suppress a restart due to unconsumed socket contents. As the socket buffer is cleared, the socket is returned to the initial listening state, so new data arriving in the socket may yet again trigger the service. With ClearSocket=true is guaranteed it will not be the former contents of the buffer that started the earlier instance of the service that had failed or been stopped by the user. Defaults to false, i.e. socket's contents are not cleared following a service's spontaneous failure or a offlining. Version-Release number of selected component (if applicable): systemd-239 and later Additional info: To enable this functionality with current implementation, a solution already exists with playing with the service unit definition, but this leads to error messages in the journal, which may be confusing. The solution consists in stopping the socket from listening in ExecStopPost of the service unit, making sure the service always fails in ExecStopPost and using "OnFailure" to start the socket again, as shown below: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [Unit] OnFailure=<myservice>.socket [Service] ... ExecStopPost=/bin/bash -c '/bin/echo "Stopping socket listener"; /bin/systemctl stop <myservice>.socket' ExecStopPost=/bin/false -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- With this in place, upon service stopping/dying, the socket will be stopped then immediately restarted (thanks to OnFailure).