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:
When a ssh client disconnect from server, the user session gets closed through executing *pam_systemd* hooks, which leads to getting a "Hello" then "ReleaseSession" dbus call.
In case the remote program exits while *pam_systemd* executes the dbus call, the following error message is logged:
~~~
pam_systemd(sshd:session): Failed to release session: Interrupted system call
~~~
Digging into this the whole day, I could find that the root cause is a bug in ppoll() call in dbus_poll() code:
~~~
2787 static int bus_poll(sd_bus *bus, bool need_more, uint64_t timeout_usec) {
:
2839 r = ppoll(p, n, m == (uint64_t) -1 ? NULL : timespec_store(&ts, m), NULL);
2840 if (r < 0)
2841 return -errno;
:
~~~
Here above on line 2839 there is no check for special errnos EAGAIN and EINTR, which can be returned legitimately, per poll(2) manpage:
~~~
ERRORS
EINTR A signal occurred before any requested event; see signal(7).
NOTES
On some other UNIX systems, poll() can fail with the error EAGAIN if the system fails to allocate kernel-in‐
ternal resources, rather than ENOMEM as Linux does. POSIX permits this behavior. Portable programs may
wish to check for EAGAIN and loop, just as with EINTR.
~~~
I don't know if not having the session be closed properly is an issue or not, but likely it's possible that any dbus client calling dbus_poll() can hit this.
Version-Release number of selected component (if applicable):
systemd-219
How reproducible:
Always
Steps to Reproduce:
I could not automatize the reproducer. The reproducer consists in disconnecting the client, and pausing dbus-daemon so that pam_systemd "hangs" on dbus Hello, while stopping the remote command.
1. Create a script looping forever until told to exit
~~~
# cat /usr/local/bin/diewhentold
#!/bin/sh
/bin/rm /run/dienow 2>/dev/null
while [ ! -e /run/dienow ]; do
sleep 0.5
done
~~~
2. Start the script through ssh
~~~
$ ssh localhost /usr/local/bin/diewhentold
~~~
3. In another terminal, stop dbus-daemon through using gdb and prepare the command to let the script stop (but don't execute it yet)
~~~
$ gdb /usr/bin/dbus-daemon $(pgrep dbus-daemon)
(gdb) !touch /run/dienow
~~~
4. Background the ssh command and kill it
~~~
$ ^Z
$ kill %1
~~~
5. In gdb terminal, tell the script to execute by really executing the "touch" command
Actual results:
Oct 25 16:18:53 vm-rhel7 sshd[8096]: pam_systemd(sshd:session): Failed to release session: Interrupted system call
Expected results:
Session closed properly
Comment 4RHEL Program Management
2022-10-26 14:18:58 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Description of problem: When a ssh client disconnect from server, the user session gets closed through executing *pam_systemd* hooks, which leads to getting a "Hello" then "ReleaseSession" dbus call. In case the remote program exits while *pam_systemd* executes the dbus call, the following error message is logged: ~~~ pam_systemd(sshd:session): Failed to release session: Interrupted system call ~~~ Digging into this the whole day, I could find that the root cause is a bug in ppoll() call in dbus_poll() code: ~~~ 2787 static int bus_poll(sd_bus *bus, bool need_more, uint64_t timeout_usec) { : 2839 r = ppoll(p, n, m == (uint64_t) -1 ? NULL : timespec_store(&ts, m), NULL); 2840 if (r < 0) 2841 return -errno; : ~~~ Here above on line 2839 there is no check for special errnos EAGAIN and EINTR, which can be returned legitimately, per poll(2) manpage: ~~~ ERRORS EINTR A signal occurred before any requested event; see signal(7). NOTES On some other UNIX systems, poll() can fail with the error EAGAIN if the system fails to allocate kernel-in‐ ternal resources, rather than ENOMEM as Linux does. POSIX permits this behavior. Portable programs may wish to check for EAGAIN and loop, just as with EINTR. ~~~ I don't know if not having the session be closed properly is an issue or not, but likely it's possible that any dbus client calling dbus_poll() can hit this. Version-Release number of selected component (if applicable): systemd-219 How reproducible: Always Steps to Reproduce: I could not automatize the reproducer. The reproducer consists in disconnecting the client, and pausing dbus-daemon so that pam_systemd "hangs" on dbus Hello, while stopping the remote command. 1. Create a script looping forever until told to exit ~~~ # cat /usr/local/bin/diewhentold #!/bin/sh /bin/rm /run/dienow 2>/dev/null while [ ! -e /run/dienow ]; do sleep 0.5 done ~~~ 2. Start the script through ssh ~~~ $ ssh localhost /usr/local/bin/diewhentold ~~~ 3. In another terminal, stop dbus-daemon through using gdb and prepare the command to let the script stop (but don't execute it yet) ~~~ $ gdb /usr/bin/dbus-daemon $(pgrep dbus-daemon) (gdb) !touch /run/dienow ~~~ 4. Background the ssh command and kill it ~~~ $ ^Z $ kill %1 ~~~ 5. In gdb terminal, tell the script to execute by really executing the "touch" command Actual results: Oct 25 16:18:53 vm-rhel7 sshd[8096]: pam_systemd(sshd:session): Failed to release session: Interrupted system call Expected results: Session closed properly