tickets #126236
openpam_systemd(crond:session): Failed to create session: Maximum number of sessions (8192) reached, refusing further sessions.
0%
Description
mailman3 (lists.o.o):~ # loginctl list-sessions
SESSION UID USER SEAT TTY
56633 1366800142 crameleon pts/0
c10001 4200 mailman
c10003 4200 mailman
c10004 4200 mailman
c10005 4200 mailman
There is in fact 8192 "active" sessions. However, "crameleon" is not on pts/0, that is me.
Updated by pjessen 6 months ago
crameleon wrote:
Why would there be so many
mailman
sessions?
I have no idea, it seems to be some sort of clean-up problem.
I have just now logged in -
- 8192 active sessions
- 7858 mailman
- 327 root
- 6 nobody
- 1 crameleon
"your" session is ancient, from 2022-12-30. I can't tell if the situation is actually a real problem, it doesn't look like it.
I looked at the session list, it goes back to 2022-12-25 19:57:27 and ends on 2022-12-31 12:52:01 (which is maybe when it ran full).
The 8192 limit is the default, from /etc/systemd/logind.conf.
Updated by crameleon 6 months ago
The limit is a reasonable value, those stale sessions seem weird to me - the root and crameleon ones seem like some stale ones the system did not clean up, but the mailman ones shouldn't exist in the first place, or at least not in such a high amount (a couple would be understandable if people enter login sessions to the mailman account, but that should be relatively proportional to the sessions of the respective administrator's $USER).
Updated by pjessen 6 months ago
cboltz wrote:
I'd guess that all these mailman sessions get started for cronjobs or timers.
Killing them is worth a try, with a quite small risk (if something breaks, restart mailman or reboot the VM).
I already tried killing the crameleon session, didn't work. He's still here :-) Mailman's been restarted more than once. I'm more in favour of rebooting, but I would prefer to understand what's going on ... I googled the error message, quite a few hits, but I didn't get anywhere.
Updated by crameleon 6 months ago
I googled the error message, quite a few hits, but I didn't get anywhere.
I'd say error message is perfectly valid, there are too many sessions.
I already tried killing the crameleon session, didn't work. He's still here
I tried loginctl kill-session 56633
, which returned "Could not kill session: No such file or directory", whilst loginctl show-session 56633
returned session information. Weird. I then killed all my user processes with pkill -u crameleon
, which worked, as no more processes under my user were reported by ps
, but loginctl list-sessions|grep crameleon
still showed the ghost session. I then restarted the login manager using systemctl restart systemd-logind
, after which my ghost session was no longer to be found by any of the loginctl subcommands.
As an added bonus, the couple thousand other sessions are now gone as well, but one "mailman" one immediately popped up again.
Updated by pjessen 6 months ago
crameleon wrote:
I googled the error message, quite a few hits, but I didn't get anywhere.
I'd say error message is perfectly valid, there are too many sessions.
Right, but why? Something is clearly wrong, all of the sessions are ancient and invalid.
I then restarted the login manager using
systemctl restart systemd-logind
, after which my ghost session was no longer to be found by any of the loginctl subcommands. As an added bonus, the couple thousand other sessions are now gone as well, but one "mailman" one immediately popped up again.
Looking right now, I only see my own session. I guess we'll notice if it happens again. Maybe I'll add a quick daily logscan. What I find particularly interesting is that too many sessions does not seem to cause any problems.
Updated by crameleon about 2 months ago
- Assignee deleted (
hellcp)
Maybe this is resolved with my upgrade to a recent Tumbleweed snapshot. It was about half a year old.