Your message dated Sat, 1 Feb 2020 05:59:36 +0100
with message-id <[email protected]>
and subject line Re: Bug#813789: systemd: su -l does not start/attach to user
session
has caused the Debian Bug report #813789,
regarding systemd: su -l does not start/attach to user session
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
813789: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813789
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 215-17+deb8u2
Severity: normal
Hi,
I keep seeing in various places (Debian-related and otherwise) that
su does not start a new systemd user session because it is not a
proper login. The symptom is:
# su -l boris
$ systemctl --user status
Failed to get D-Bus connection: Connection refused
To me, it seems su -/-l/--login is just like login (what is the
conceptual difference between su -l boris and ssh [email protected]?).
It also does not attach to a (lingering) user session, unless I
manually do:
export XDG_RUNTIME_DIR=/run/user/`id -u`
[Note that in this case XDG_SESSION_ID will still be bogus but
apparently it is harmless since it is for information purposes
only.]
It seems the decision whether it is a proper login or not is
made somewhere in /etc/pam.d/. While looking through the files
I noticed that the runuser-l file in this directory (but not
runuser) contains this line:
-session optional pam_systemd.so
While this may seem like it should be the solution, runuser -l
still doesn't start/attach to the user session. So the purpose
of this extra line is still a mystery to me.
For completeness, let me mention /usr/share/pam-configs/systemd
which seems related but I am not sure how.
-- Package-specific info:
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-59
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-6
ii libc6 2.19-18+deb8u1
ii libcap2 1:2.24-8
ii libcap2-bin 1:2.24-8
ii libcryptsetup4 2:1.6.6-5
ii libgcrypt20 1.6.3-2
ii libkmod2 18-3
ii liblzma5 5.1.1alpha+20120614-2+b3
ii libpam0g 1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-17+deb8u2
ii mount 2.25.2-6
ii sysv-rc 2.88dsf-59
ii udev 215-17+deb8u2
ii util-linux 2.25.2-6
Versions of packages systemd recommends:
ii dbus 1.8.20-0+deb8u1
ii libpam-systemd 215-17+deb8u2
Versions of packages systemd suggests:
pn systemd-ui <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Reading the upstream bug report, it appears what you get is expected
behaviour. The short summary
"Long story short: "su" is really a broken concept. It will given you
kind of a shell, and it's fine to use it for that, but it's not a full
login, and shouldn't be mistaken for one."
You can either use ssh, a real login or
machinctl shell [email protected]
See man machinectl for more details
Regards,
Michael
signature.asc
Description: OpenPGP digital signature
--- End Message ---
