Hi. Failure to create the session is almost certainly the reason why the processes are in wrong slice.
Note that the PID that is in journald is PID of the process who
connected to journald obtained via getpeercred. If it forks and the fd
is passed to another process, the logs will misreport the old PID.
(Given different PIDs in very short intervals, I don't think it's the
PID of the listening sshd process but I'm not sure if sshd children
don't fork again. I'd recommend checking also neighbor PIDs found in the
logs.)
To your problem, I guess you're hitting some limits of dbus-daemon, I'd
try increasing
<limit name="max_connections_per_user">256</limit>
for you system dbus-daemon instace.
The second suggestion^W workaround would be to tweak
CPUWeight=/CPUShares= of dbus.service and sshd.service. Given
dbus.service ~2 times more that to sshd.service. This will likely cause
slightly more latency at clients but it can lower the strain on
dbus-daemon so that it brokers all pam_systemd requests.
HTH,
Michal
signature.asc
Description: PGP signature
