Project

General

Profile

Actions

tickets #126236

closed

pam_systemd(crond:session): Failed to create session: Maximum number of sessions (8192) reached, refusing further sessions.

Added by pjessen about 1 year ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Mailing lists
Target version:
-
Start date:
2023-03-20
Due date:
% Done:

0%

Estimated time:

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.

Actions #1

Updated by crameleon 12 months ago

Why would there be so many mailman sessions?

Actions #2

Updated by crameleon 12 months ago

  • Private changed from Yes to No
Actions #3

Updated by pjessen 12 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.

Actions #4

Updated by crameleon 12 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).

Actions #5

Updated by crameleon 12 months ago

Should we terminate all sessions and see if they magically grow again?

Actions #6

Updated by cboltz 12 months ago

  • Category set to Mailing lists
  • Assignee set to hellcp

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).

Actions #7

Updated by pjessen 12 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.

Actions #8

Updated by crameleon 12 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.

Actions #9

Updated by pjessen 12 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.

Actions #10

Updated by crameleon 8 months ago

  • Assignee deleted (hellcp)

Maybe this is resolved with my upgrade to a recent Tumbleweed snapshot. It was about half a year old.

Actions #11

Updated by crameleon 4 months ago

  • Status changed from New to Closed

No further reports, closing.

Actions

Also available in: Atom PDF