I now explicitly seeded libpam-systemd for server, like we do on
desktop. It is already transitively pulled in on x86, so let's make this
explicit to have a consistent install on all architectures.
We can't just bump the Recommends:, as that would pull in libpam-systemd
and dbus into a debootstrap and thus make D-Bus essential. (Which in
turn makes porting to new architectures harder, bloads up chroots,
etc.). It'd also be conceptually wrong. But I suppose "systemd" being in
the essential set is related to why its recommends are not installed by
default.
** Package changed: debian-installer (Ubuntu) => ubuntu-meta (Ubuntu)
** Changed in: ubuntu-meta (Ubuntu)
Status: Incomplete => In Progress
** Changed in: ubuntu-meta (Ubuntu)
Status: In Progress => Fix Committed
** Summary changed:
- ppc64el ubuntu-server ISO does not install libpam-systemd (not installing recommends?)
+ ppc64el ubuntu-server ISO does not install libpam-systemd
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1561658
Title:
ppc64el ubuntu-server ISO does not install libpam-systemd
Status in ubuntu-meta package in Ubuntu:
Fix Committed
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 at pts/0
│ │ └─661 -bash
│ └─user at 1000.service
│ ├─636 /lib/systemd/systemd --user
│ └─637 (sd-pam)
└─user-1003.slice
├─session-5.scope
│ ├─19379 sshd: gromero [priv]
│ ├─19404 sshd: gromero at 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 at eth0.service
│ └─1833 /sbin/dhclient
├─accounts-daemon.service
│ └─1717 /usr/lib/accountsservice/accounts-daemon
├─system-serial\x2dgetty.slice
│ └─serial-getty at 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 at 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/ubuntu-meta/+bug/1561658/+subscriptions