I checked this on a ppc64el xenial scalingstack instance, and ssh
sessions are in the expected controller:
$ egrep 'systemd|pids' /proc/self/cgroup
5:pids:/user.slice/user-1000.slice/session-2.scope
1:name=systemd:/user.slice/user-1000.slice/session-2.scope
$ cat /sys/fs/cgroup/pids//user.slice/user-1000.slice/session-2.scope/pids.max
max
What is "cat /proc/self/cgroup" in an ssh session for you? The cgroup
tree output from above is likely the name=systemd controller, but
TasksMax translates to the "pids.max" setting in the "pids" cgroup
controller.
So we need to find out what's different on your system:
- Do you see any error messages in "sudo journalctl -t sshd"?
- Does your session have a $XDG_SESSION_ID (should be a small number)?
- What is the output of "sudo journalctl -t systemd-logind", "loginctl", and
"loginctl show-session $XDG_SESSION_ID"?
- Can you please just attach the output of the full journal, just in case?
(sudo journalctl -b > /tmp/journal.txt)
Thank you!
** Summary changed:
- “Cannot fork” and "Resource temporary unavailable"
+ ppc64el ssh sessions don't run in session cgroup but in sshd's
** Changed in: systemd (Ubuntu)
Status: Confirmed => Incomplete
--
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:
ppc64el ssh sessions don't run in session cgroup but in sshd's
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
