Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#55964 - [systemd] 235-1 logind fails on opening graphical session

Attached to Project: Arch Linux
Opened by Jürgen Sauer (jojoax) - Thursday, 12 October 2017, 13:12 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 20 October 2017, 14:29 GMT
Task Type Bug Report
Category Upstream Bugs
Status Assigned
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No

Details

Description:
After System upgrading (2017-10-12) systemd-235.0-1-x86_64.pkg.tar.xz no user X11 Usersesion login was possible.
Plasma, XFCE4, Gnome failed, by thorwing a copnnect problem to dbus.
"Could not sync environment to dbus"

Displaymanager which was used: lightdm

Additional info:
* package version(s): systemd-235.0-1-x86_64.pkg.tar.xz
* config and/or log files etc.

Config is: /home is mounted from NFS V4 Server, User database is NIS (ypbind-mt), Special Dirs in $HOME are mounted localy using a btrfs subvolume from the root ssd harddisk.

root@pc6:~# systemctl status lightdm.service
● lightdm.service - Light Display Manager
Loaded: loaded (/usr/lib/systemd/system/lightdm.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2017-10-12 14:53:59 CEST; 26s ago
Docs: man:lightdm(1)
Main PID: 992 (lightdm)
Tasks: 14 (limit: 4915)
CGroup: /system.slice/lightdm.service
├─ 992 /usr/bin/lightdm
├─1009 /usr/lib/xorg-server/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
├─1019 lightdm --session-child 13 16
└─1030 /usr/bin/gnome-keyring-daemon --daemonize --login

Okt 12 14:53:59 pc6 systemd[1]: Starting Light Display Manager...
Okt 12 14:53:59 pc6 systemd[1]: Started Light Display Manager.
Okt 12 14:54:00 pc6 lightdm[992]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Okt 12 14:54:00 pc6 lightdm[1019]: pam_succeed_if(lightdm-autologin:auth): requirement "user ingroup autologin" was met by user "jojo"
Okt 12 14:54:00 pc6 lightdm[1019]: gkr-pam: no password is available for user
Okt 12 14:54:00 pc6 lightdm[992]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Okt 12 14:54:00 pc6 lightdm[1019]: pam_unix(lightdm-autologin:session): session opened for user jojo by (uid=0)
Okt 12 14:54:25 pc6 lightdm[1019]: pam_systemd(lightdm-autologin:session): Failed to create session: Connection timed out
Okt 12 14:54:25 pc6 lightdm[1019]: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files

Also on Session startup the tmpfs mount for /run/user/$UID is missing.

journalctl -xe shows:
Okt 12 14:54:25 pc6 lightdm[1019]: pam_systemd(lightdm-autologin:session): Failed to create session: Connection timed out
Okt 12 14:54:25 pc6 lightdm[1019]: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
Okt 12 14:54:27 pc6 ksplashqml[1057]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-jojo'
Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined
Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:88: ReferenceError: bottomRect is not defined
Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined
Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:88: ReferenceError: bottomRect is not defined

Steps to reproduce:
1. Get Home from company server (here a Debian V9 exporting /home the classical, refer arch wiki)

server:/home /home nfs nofail,_netdev,x-systemd.requires=network-online.target,x-systemd.device-timeout=1 0 0
server:/srv/pkg /var/cache/pacman/pkg nfs nofail,_netdev,x-systemd.requires=network-online.target,x-systemd.device-timeout=1 0 0

2. mount User special directories like (this was done due performance issues with kde and thunderbird)
LABEL=pc6root /home/jojo/.config btrfs _netdev,subvol=jojo/config,rw,relatime,space_cache,ssd_spread,ssd,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0
LABEL=pc6root /home/jojo/.local btrfs _netdev,subvol=jojo/local,rw,relatime,space_cache,discard,ssd,ssd_spread,compress=lzo,x-systemd.requires=remote-fs.target 0 0
LABEL=pc6root /home/jojo/.cache btrfs _netdev,subvol=jojo/cache,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0
LABEL=pc6root /home/jojo/.kde btrfs _netdev,subvol=jojo/kde,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0
LABEL=pc6root /home/jojo/.kde4 btrfs _netdev,subvol=jojo/kde4,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0
LABEL=pc6root /home/jojo/.thunderbird btrfs _netdev,subvol=jojo/email,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0

3- Install NIS Environment to get user auth via nis (refer arch wiki)
- use lightdm and try to login with any user with a standard user session, which is using dbus like plasma, xfce, gnome


... creating the session fails here at 3 systems.

After downgrading to
root@pc6:/var/cache/pacman/pkg# pacman -U systemd-234.11-9-x86_64.pkg.tar.xz systemd-sysvcompat-234.11-9-x86_64.pkg.tar.xz

Everything was working again.

Bug was classified by mine "critical" due no usefull workig or using the system is possible.

This task depends upon

Comment by Jürgen Sauer (jojoax) - Friday, 13 October 2017, 16:27 GMT
I also opened systemd-logind Bug report @github:
https://github.com/systemd/systemd/issues/7074

Looks like a confirmation was received there from 3rd party side.
Comment by M Bou (mpour_) - Sunday, 15 October 2017, 08:27 GMT
For me downgrading does not solve the issue :/
Comment by Jürgen Sauer (jojoax) - Tuesday, 17 October 2017, 06:43 GMT Comment by Eli Schwartz (eschwartz) - Wednesday, 18 October 2017, 16:24 GMT
  • Field changed: Summary (systemd-logind Version 235-1 fails on openin Users Session [plasma | xfce4 | gnome ] → [systemd] 235-1 logind fails on opening graphical session)
  • Field changed: Category (Packages: Core → Upstream Bugs)
  • Field changed: Architecture (x86_64 → All)
  • Field changed: Severity (Critical → High)
  • Task assigned to Dave Reisner (falconindy), Christian Hesse (eworm)
https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Severity
Critical means boot failure or system crash, if I am reading this correctly laggy login with NIS users and failure to start a GUI is not quite as severe.

According to the bugreport, "IPAddressDeny=any" in systemd-logind.service can be commented out to fix things.
Comment by Jürgen Sauer (jojoax) - Thursday, 19 October 2017, 07:57 GMT
> Critical means boot failure or system crash, if I am reading this correctly laggy login with NIS users and failure to start a GUI is not quite as severe.

Critcal is correct, because this is a mature boot failure.
Even here no login, even for "root" is possible and no services are running correctly.
This is a mature boot failure.
Comment by Heinrich Siebmanns (Harvey) - Wednesday, 01 November 2017, 07:49 GMT
This caused my nis network logins to fail after the update to v235. Commenting out "IPAddressDeny" in /usr/lib/systemd/system/systemd-logind.service brought me back into business. Archlinux will have to decide what to do, either to patch out the IP sandboxing or at least give some hints on the wiki pages for nis, pam_mount and suchlike. Maybe it is worth a news item on the home page?

Ah, and btw the logind failure (without "IPAddressDeny" commented out) in the actual state leads to a systemd watchdog reset after 3 minutes of the whole machine which is fairly critical in my opinion...
Comment by Dave Reisner (falconindy) - Wednesday, 01 November 2017, 11:05 GMT
...or you can just report such things upstream.
Comment by Heinrich Siebmanns (Harvey) - Wednesday, 01 November 2017, 11:46 GMT
It is reported upstreams and it seems it won't be changed if you read the last comment from poettering 12 days ago. Again:
https://github.com/systemd/systemd/issues/7074
Comment by Dave Reisner (falconindy) - Wednesday, 01 November 2017, 12:08 GMT
Does using nscd, as suggested, work?
Comment by Heinrich Siebmanns (Harvey) - Wednesday, 01 November 2017, 12:39 GMT
no, at least not out of the box for NIS login to KDE via sddm while if "IPAddressDeny" is commented it works.
Comment by Dave Reisner (falconindy) - Wednesday, 01 November 2017, 14:22 GMT
I'd encourage you to figure out the necessary changes such that nscd does work with your setup.
Comment by Heinrich Siebmanns (Harvey) - Thursday, 02 November 2017, 08:24 GMT
I may be wrong, but nscd is a name cache daemon, isn't it? And by design caches have to be refreshed from time to time. What if something changes while the machine is offline? Looks like a time bomb to me...
Comment by Dave Reisner (falconindy) - Thursday, 02 November 2017, 11:43 GMT
A little dramatic, no? Read nscd.conf(5) and set your TTLs accordingly.
Comment by Jürgen Sauer (jojoax) - Thursday, 02 November 2017, 12:03 GMT
It is dramatic.
Without any hints to this behavior many things are broken. i.E. Login into such a system at all.

Without any hint to this catastrophic changes it results like denial of service attack.

If such a change is nessesary it must be mentioned onto a well seen announcement, not like a secret way like it came into the system.

We administrators here are not personally see, why it was nessessary to disable any login possibility like it was done here.
Comment by Dave Reisner (falconindy) - Thursday, 02 November 2017, 13:21 GMT
> Without any hints to this behavior many things are broken. i.E. Login into such a system at all.
Yes, that's often how undocumented changes upstream are discovered -- users report them to bug trackers. I appreciate you taking that step.

> We administrators here are not personally see, why it was nessessary to disable any login possibility like it was done here.
Upstream acknowledges the change, gave you the rationale for the change and why it won't be reverted, and offered a workaround.

It's unlikely that Arch will change anything here.
Comment by Heinrich Siebmanns (Harvey) - Thursday, 02 November 2017, 13:31 GMT
> Without any hints to this behavior many things are broken. i.E. Login into such a system at all.

Yep, that's the point. Only lokal root can safely log in to such a borked machine. And nscd is another daemon brought in without any reason other than not to change systemd's behaviour. One potential hole closed, another opened. I prefer changing the default behaviour. But that's everyone's own choice.

And what's the argument against a news item?
Comment by Leonid Isaev (lisaev) - Saturday, 11 November 2017, 05:56 GMT
I don't understand, if logind needs to talk over network to log users in, why is it forbidden to do so? Why do I need to run an additional daemon on all nis clients now?

Also, this "feature" is broken inside containers. I have an archlinux host which is a nis client and an archlinux container, also a client within the same domain. Both use the same nsswitch.conf (that has nis entries). Yet, the container is working perfectly with the default logind.service while the host fails to log users in.
Comment by Leonid Isaev (lisaev) - Wednesday, 06 December 2017, 04:03 GMT
A few clarifications for people using a pure NIS environment (server and clients):
1. Nscd will not work in general because AFAIU it doesn't support automounter maps which can be exported by the NIS server;
2. You don't need to disable IP sandbox globally. For example, setting IPAddressAllow=localhost and IPAddressAllow=<your.nis.server.ip> in systemd-logind.service.d/ip.conf (either in /etc or /usr/lib) will restore the old behavior.

EDIT: I don't think that there is anything to be fixed in the systemd package because the completely locked down IP sandbox makes sense for most users, and administrators who deal with central auth will configure things in a tailored way...
Comment by Jürgen Sauer (jojoax) - Wednesday, 06 December 2017, 09:31 GMT
@Leonid Isaev:
Sorry, the suggested solution does not work:

root@pc6:/etc/systemd/system# cat /etc/systemd/system/systemd-logind.service.d/ip.conf
IPAddressAllow=localhost
IPAddressAllow=192.168.11.10
IPAddressAllow=192.168.11.0/24

Gives a negative result:
# systemctl status systemd-logind.service
[...]
Dez 06 10:28:44 pc6 systemd[1]: /etc/systemd/system/systemd-logind.service.d/ip.conf:1: Assignment outside of section. Ignoring.
Dez 06 10:28:44 pc6 systemd[1]: /etc/systemd/system/systemd-logind.service.d/ip.conf:2: Assignment outside of section. Ignoring.
Dez 06 10:28:44 pc6 systemd[1]: /etc/systemd/system/systemd-logind.service.d/ip.conf:3: Assignment outside of section. Ignoring.
[...]


And for Adminstrators there must be an correct documentation, which is completely missing.
Comment by Leonid Isaev (lisaev) - Wednesday, 06 December 2017, 10:47 GMT
You have to put those entries under a Service section, i.e.
[Service]
IPAddressAllow=...

See how IPAddressDeny enters systemd-logind.service.
Comment by Jürgen Sauer (jojoax) - Wednesday, 06 December 2017, 11:50 GMT
seems to work, thx.
A better admin's doc would be great.

At this time in man pages is nothing usable to read about. Also google give a great silence about.
Like a naural law, the right doc is the latest thing a developer thinks about (As here :) )

Loading...