It seems that libpam-systemd is installed as a dependency of policykit-1
on amd64. Policykit-1 is not being installed automatically on ppc64el
but on amd64.

So, I understand that we might have two solutions:

a) Install policykit-1 in ppc64el, and this will bring libpam-systemd as
a dependency

b) Makes systemd dependent of libpam-systemd.

Option b) seems to be the better than a) from a shallow point of view,
mainly because in the solution "a)" a  user can remove policykit-1 (or
even libpam-systemd) and start being bite by this problem

-- 
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

Reply via email to