pam_systemd(login:session): Failed to release session: Interrupted system call #18817
Comments
|
What's the pam stack used? Is this a getty login? |
poettering
added
login
needs-reporter-feedback ❓
The pam related packages I have are the ones that come by default in Arch Linux: I have both up to date.
Sorry for my ignorance, but didn't know what getty means. The definition I found: "getty is a program which manages a terminal line and its connected terminal. Its purpose is to protect the system from unauthorized access. Generally, each getty process is started by systemd and manages a single terminal line. " But still not sure of what should I answer to your question. |
|
What I am looking for is: which program is requesting the PAM session? The logs only say "login", which is likely getty, but might not be. getty is the thing that asks you for your username on the console when you log in there. And I also want to know the /etc/pam.d/ snippet for that service. Is there anything interesting in the logs? The excerpt you posted is jut too short to be useful, please provide more context on that. |
|
To give a little bit more of context: Like a week ago, At a given moment of the day I suddenly couldn't use sudo (the output was just: I found I post of a guy who had this exact same problem, he described that the pam module was updated and it includes using a new fail module that blocks access for your user temporarily across all terminals (rather than just the current one) on multiple incorrect password attempt. Part of the problem ended up being a script I had running with crond and using root access, which was failing and made the pam module to kick in. This was the output on journalctl I removed my script, and the pam module stopped to fail because of CROND. Whoever the problem is still there. My journalctl is still fill with those Finally, I did a post on Reddit and turns out there is a bunch of other people with the same problem. Some of them didn't even a have cronjob. That's the reason I decided to open an issue, apparently the is more people with the same problem. This is a new install, and every single day my journalctl is having a few
I think that the program is sudo, in my first comment, the link to the gist shows that most of the errors start with sudo. I really don't know how to debug this in a way to be 100% sure that the program is sudo. But that's what it seems like. And if I check my journalctl it is still the same, most of those errors start with login or sudo. Example:
|
|
Hmm, you closed this? Did you figure it out? |
Oh sorry for the late response, I didn't see the message. No I didn't figured it out, I still have the same messages on my journaltctl every now and then ( I decided to close because I wasn't having any mayor problem that were caused by those errors in journalctl . The whole situation where I couldn't use sudo for a certain period of time was because of the cronjob I had as root, as explained before. So in conclusion those errors doesn't seem to be anything that I have to be extremely worry about. |
|
FYI, I get this same error frequently, but only when rebooting a server. See below for more logging around a recent example. This was on openSUSE Leap 15.2 with openSUSE's Without doing a full analysis, it seems like the most likely explanation is that during the flurry of activity that occurs on shutdown, systemd receives a signal in the middle of an I/O system call, that sysytem call returns For example, possibly this code (and many other similar examples): int bus_socket_write_message(sd_bus *bus, sd_bus_message *m, size_t *idx) {
struct iovec *iov;
ssize_t k;
...
if (bus->prefer_writev)
k = writev(bus->output_fd, iov, m->n_iovec);
else {
struct msghdr mh = {
.msg_iov = iov,
.msg_iovlen = m->n_iovec,
};
...
k = sendmsg(bus->output_fd, &mh, MSG_DONTWAIT|MSG_NOSIGNAL);
if (k < 0 && errno == ENOTSOCK) {
bus->prefer_writev = true;
k = writev(bus->output_fd, iov, m->n_iovec);
}
}Note that both If one would expect The code above is invoked (indirectly) from here, which is where the _public_ PAM_EXTERN int pam_sm_close_session(
pam_handle_t *handle,
int flags,
int argc, const char **argv) {
...
id = pam_getenv(handle, "XDG_SESSION_ID");
if (id && !existing) {
_cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
/* Before we go and close the FIFO we need to tell logind that this is a clean session
* shutdown, so that it doesn't just go and slaughter us immediately after closing the fd */
r = pam_acquire_bus_connection(handle, &bus);
if (r != PAM_SUCCESS)
return r;
r = bus_call_method(bus, bus_login_mgr, "ReleaseSession", &error, NULL, "s", id);
if (r < 0) {
pam_syslog(handle, LOG_ERR, "Failed to release session: %s", bus_error_message(&error, r));
return PAM_SESSION_ERR;
}
}And yes, this is a bug, not an "error", because any process that is doing blocking system calls while possibly receiving a signal must be prepared to handle Logging around recent example: |
|
I saw the issue on my Archlinux too. And It caused my machine to hang on reboot. |
|
I have also encountered this error message on a Debian system. The reason I looked is because it took unexpectedly long to shut down, but that might have been caused by something else. Though it seems to me a fix has been merged for version 250, and my system is currently on 247 (based on |
bus_ppoll() relies on ppoll(2) which can return EINTR when interrupted by a signal. bus_ppoll() should be prepared to handle this case properly by restarting the system call. Hence let's make it call safe_ppoll_usec() instead since it does that automatically for us. This should address one of the cases that lead to the following error, which might occur when shutting down the system: login[1489]: pam_systemd(login:session): Failed to release session: Interrupted system call IOW this patch closes one possible root cause of issue systemd#18817.
bus_ppoll() relies on ppoll(2) which can return EINTR when interrupted by a signal. bus_ppoll() should be prepared to handle this case properly by restarting the system call. Hence let's make it call safe_ppoll_usec() instead since it does that automatically for us. This should address one of the cases that lead to the following error, which might occur when shutting down the system: login[1489]: pam_systemd(login:session): Failed to release session: Interrupted system call IOW this patch closes another possible root cause of issue systemd#18817.
systemd version the issue has been seen with
Used distribution
CPU architecture issue was seen on
Expected behaviour you didn't see
Unexpected behaviour you saw
Additional program output to the terminal or log subsystem illustrating the issue
The text was updated successfully, but these errors were encountered: