A-ha! So there's no logind session, and indeed if I remove pam_systemd.so from /etc/pam.d/common-session I get the same effect.
Do you have "session optional pam_systemd.so" in /etc/pam.d/common-session ? If so, it fails for some reason and we need to find out why. But there's no trace of an error, or it trying to create a session in the journal, so it's more likely just missing. Assuming that it is missing indeed, how was this system installed? Do you do any customizations to that file? Normally this is handled automatically by pam-auth-update. If you run that (via sudo), it should have "Create cgroups for user login sessions" enabled, and create a file with pam_systemd. What happens there? ** Summary changed: - ppc64el ssh sessions don't run in session cgroup but in sshd's + ssh sessions don't run in session cgroup but in sshd's ** Summary changed: - ssh sessions don't run in session cgroup but in sshd's + ssh sessions don't run in session cgroup but in sshd's -- pam_systemd missing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1561658 Title: ssh sessions don't run in session cgroup but in sshd's -- pam_systemd missing Status in systemd package in Ubuntu: Incomplete Bug description: On Ubuntu 16.04/ppc64el, the cgroup for a user session (bash) inherits from a sshd.service, when the user logs into the machine using SSH. This causes the amount of process to be limited by /etc/systemd/system/conf DefaultTasksMax=512 This does not seem to happen on amd64. This is a cgroup tree diff: On x64, bash (in this case, PID 19405 ) spawned by sshd belongs to CGROUP session-5.scope->user-1003.slice->user.slice: └─user.slice ├─user-1000.slice │ ├─session-1.scope │ │ ├─634 sshd: brenohl [priv] │ │ ├─660 sshd: brenohl@pts/0 │ │ └─661 -bash │ └─user@1000.service │ ├─636 /lib/systemd/systemd --user │ └─637 (sd-pam) └─user-1003.slice ├─session-5.scope │ ├─19379 sshd: gromero [priv] │ ├─19404 sshd: gromero@pts/1 │ ├─19405 -bash However, in ppc64le, bash (in this case, PID 1913), spawned by sshd belongs to CGROUP ssh.service->system.slice->-.slice: -.slice ├─1720 /sbin/cgmanager -m name=systemd ├─init.scope └─system.slice ├─dbus.service │ └─1699 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ├─cron.service │ └─1702 /usr/sbin/cron -f ├─ifup@eth0.service │ └─1833 /sbin/dhclient ├─accounts-daemon.service │ └─1717 /usr/lib/accountsservice/accounts-daemon ├─system-serial\x2dgetty.slice │ └─serial-getty@hvc0.service │ └─1875 /sbin/agetty --keep-baud 115200 38400 9600 hvc0 vt220 ├─systemd-journald.service │ └─1382 /lib/systemd/systemd-journald ├─systemd-timesyncd.service │ └─1639 /lib/systemd/systemd-timesyncd ├─ssh.service │ ├─1863 /usr/sbin/sshd -D │ ├─1897 sshd: gromero [priv] │ ├─1912 sshd: gromero@pts/0 │ ├─1913 -bash Having the user session associated with the systemd cgroups (/system.slice/ssh.service) instead of normal user/session cgroups (as user-XXXX.slice/session-5.scope), causes the process to be limited to the systemd TasksMax limit, thus, causing "Cannot fork" and "Resource temporary unavailable" problems when the amount of processes reaches this 512 limit. Gustavo Romero has more details about this problem, and will comment soon. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1561658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
