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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1561658
Title:
ppc64el ssh sessions don't run in session cgroup but in sshd's
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1561658/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
