Error message: pam_systemd(su:session): Cannot create session: Already running in a session

[Laurent Bonnaud]

Hi,

here is how to reproduce this error:

1. log in to the root account with ssh
2. run "su - some_user_account"

Here is what I see in the logs:

Feb 28 15:21:45 xeelee su[9843]: Successful su for bonnaudl by root
Feb 28 15:21:45 xeelee su[9843]: + /dev/pts/10 root:bonnaudl
Feb 28 15:21:45 xeelee su[9843]: pam_unix(su:session): session opened for user bonnaudl by root(uid=0)
Feb 28 15:21:45 xeelee su[9843]: pam_systemd(su:session): Cannot create session: Already running in a session
Feb 28 15:21:48 xeelee su[9843]: pam_unix(su:session): session closed for user bonnaudl

In another usage scenario of "su -" there is no error message and the creation of a new session:

févr. 28 15:08:15 vougeot su[18962]: Successful su for bonnaudl by root
févr. 28 15:08:15 vougeot su[18962]: + /dev/pts/0 root:bonnaudl
févr. 28 15:08:15 vougeot su[18962]: pam_unix(su:session): session opened for user bonnaudl by bonnaudl(uid=0)
févr. 28 15:08:15 vougeot systemd-logind[1162]: New session c9 of user bonnaudl.
févr. 28 15:08:15 vougeot systemd[1]: Started Session c9 of user bonnaudl.
févr. 28 15:08:17 vougeot su[18962]: pam_unix(su:session): session closed for user bonnaudl
févr. 28 15:08:17 vougeot systemd-logind[1162]: Removed session c9.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: libpam-systemd 231-9ubuntu3
Uname: Linux 4.10.1-041001-generic x86_64
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Feb 28 15:21:09 2017
EcryptfsInUse: Yes
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[spit4520 (spit4520)]

I have 32 machines under my control and all of them are experiencing the same issue. I have found some email archives from the debian project and I have found some documentation that I think could be helpful.

trying to run su with (-, -l,--login) or on its own causes the issue. su does invoke a call out to pam_systemd.so (according to docs and logs), but systemd will see that the process (su in this case) is already in a existing session (the session of the user you are trying to switch from) and it will exit out failing to make a new session for the user because it is reading that the sessions for the origin user exists instead of creating a logind sessions for the destination user. If you use ssh and login on the loop back interface everything works out fine, but the system I am using is being run by a daemon that is run as root and needs to switch to a desired user to start up x sessions for the users. We just moved away from a ssh key system for the remote server's because it was becoming too cumbersome to debug especially as we plan to expand to more machines.

I read that it is possibly a POSIX standard that declares that logind is not supposed to be called when calling su and that is why this behavior exists, but if that is the case why does the desired functionality (the starting of logind and setting of XDG_SESSION_ID and XDG_SESSION_ID environment variables) exist in Ubuntu 14.04.x?

If this is determined to not be a bug and expected functionality from here on out what reasonable work around do you suggest to allow a program running as root either call su to become a new user and start an x server or use setuid() in a C program and start a new x server for the user with the aforementioned desired variables intact?

If this is determined to be a bug and it won't be fixed in 16.04.3++ what work around do you suggest be used to achieve the desired result?

I would like to strongly suggest that this be accepted as a bug and rejected as desired behavior, switching the user should go through the PAM authentication and startup and required services for the user. su - "user" should yield a shell the equivalent of ssh "user" if they both are using PAM they should yield the same result.

debian explination:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813789

debian pseudo patch:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814670

xinit work around (old but good reading material):

        http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html

ubuntu forums post from 2012-2013 with similar issue:

        https://askubuntu.com/questions/362403/how-to-create-a-new-logind-session-while-running-xinit-from-the-console

[Laurent Bonnaud (laurent-bonnaud)]

This bug no longer exists in Ubuntu 19.04/disco.

Here is the log I get when I do ssh then "su -":

Apr 10 14:08:42 xeelee systemd[1]: Started User Manager for UID 0.
Apr 10 14:08:42 xeelee systemd[1]: Started Session 447 of user root.
Apr 10 14:08:42 xeelee systemd[28391]: Reached target Default.
Apr 10 14:08:42 xeelee systemd[28391]: Startup finished in 75ms.
Apr 10 14:08:47 xeelee su[28502]: (to bonnaudl) root on pts/30
Apr 10 14:08:47 xeelee su[28502]: pam_unix(su-l:session): session opened for user bonnaudl by root(uid=0)
Apr 10 14:09:08 xeelee su[28502]: pam_unix(su-l:session): session closed for user bonnaudl

I still get this error:

$ systemctl --user status
Failed to connect to bus: No such file or directory

but this is for another bug report...

[dundir (dundir)]

I'm receiving this error on 18.04.2 LTS. Will the fix for this will be backported for the LTS releases?