13.1 -> 13.2 (KDE): No active session

Having updated two notebooks to 13.2, the same happens on both:

  • Logging into KDE via KDM no session is registered (loginctl returns “0 sessions listed”)
  • Effects observed so far: Apper and pulseaudio cannot authenticate
  • Workaround: Logging into IceWM, the session gets registered and survives relogging into KDE
  • Checked and rebuilt PAM systemd config, no effect. Chance was low as IceWM works. No diffs found compared to 13.1 config on a third notebook
  • polkitd as well as polkit-kde-authentication-agent-1 are running
  • As well, no polkit rule related diffs found compared to 13.1

Which configuration effects this KDM / KDE behavior?

Thanks a lot for any help.

Have you tried a different user?

When you’re first logged into KDE, what is reported by the following?

ps ax|grep polkit

For reference, I get

 607 ?        Ssl    0:00 /usr/lib/polkit-1/polkitd --no-debug
 1542 ?        Sl     0:00 /usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1
10897 pts/2    S+     0:00 grep --color=auto polkit

Check that systemd-logind is running too

systemctl status systemd-logind

Have tried three different users, same effect.
But while testing this, I realized that the symptom only occurs on the initial KDE login. Logging out and in again (with the same user), the session gets registered correctly.

Interesting. I haven’t come across others reporting this behaviour (following openSUSE 13.1 to 13.2 upgrade), but could well be useful to others who come searching. :slight_smile:

systemd-logind.service - Login Service is active (running) while there are 0 sessions listed by loginctl.

Mine looks quite similar

  947 ?        Ssl    0:00 /usr/lib/polkit-1/polkitd --no-debug
 1899 ?        Sl     0:00 /usr/lib64/libexec/polkit-kde-authentication-agent-5 -session 102281d921e1c5000141980742900000016660008_1420152317_562510
 2672 pts/1    S+     0:00 grep --color=auto polkit

while loginctl reports 0 sessions listed.

Just to clarify, now that you have logged out and back in (for given users), are sessions being created at login following a reboot?

Getting closer… Seems to be a timing issue. Waiting for a minute before initially logging in the session is registered correctly. Strangely enough, the two notebooks are quite distinct with regards to performance. One 32-bit dual core, the other 64-bit quad core (a way faster), but same behavior.

Any hint?

Reproducibility: Always (no session following (re)boot when instantly logging in).

Waiting on KDM (after (re)boot) for a certain amount of time before launching the login, the session is registered correctly => timing issue

Yes, definitely something unusual going on here.

The following may be helpful here

man systemd-analyze

In particular

systemd-analyze critical-chain
systemd-analyze blame

It is likely that you are impacted by the following bug

https://bugzilla.opensuse.org/show_bug.cgi?id=905639

If you enable autofs, the system will not boot correctly anymore. This is easily reproducible by installing the openSUSE 13.2 DVD in VirtualBox, take all the defaults, including KDE, do “systemctl enable autofs.service”, and reboot:

  1. It will take 30-60 seconds until the KDE user is automatically logged in.
  2. Without autologin, the first login will take about 10-20 seconds. No matter if on tty or in kdm.
  3. The first login will get not a systemd-logind session. That is, loginctl lists no sessions. All applications that need such a session, like NetworkManager, will not work correctly!
  4. A logout and login makes everything work again. That is, the second and all subsequent logins work.

That seems to be the deal. I´m using autofs to mount remote NFS shares on demand. But according to the blame option, Network Manager (which is also mentioned in the bug report) is the gangster:


         25.081s NetworkManager.service
          3.038s systemd-udev-settle.service
           923ms postfix.service
           874ms rtkit-daemon.service
           831ms tlp.service
           551ms systemd-fsck-root.service
           329ms SuSEfirewall2.service
           326ms apparmor.service
           297ms vboxadd.service
           207ms systemd-rfkill@rfkill0.service
           175ms SuSEfirewall2_init.service
           157ms systemd-rfkill@rfkill1.service
           156ms systemd-backlight@backlight:intel_backlight.service
           121ms ModemManager.service
           117ms rpcbind.service
           107ms display-manager.service
           101ms home.mount
           100ms systemd-udev-root-symlink.service
           100ms systemd-rfkill@rfkill2.service
            97ms sys-kernel-debug.mount
            96ms dev-mqueue.mount
            93ms dev-hugepages.mount
            69ms systemd-udev-trigger.service
            64ms alsa-restore.service
            63ms rsyslog.service
            63ms upower.service
            62ms autofs.service
            60ms udisks2.service
            57ms bluetooth.service
            56ms systemd-user-sessions.service
            55ms nscd.service
            50ms avahi-daemon.service
            44ms systemd-readahead-replay.service
            43ms lvm2-activation-early.service
            43ms lvm2-activation.service
            41ms systemd-modules-load.service
            41ms rc-local.service

Thanks a lot for this tip. Now I know what can be done until a fix will be available. Will double check by disabling autofs.

Disabling autofs.service and rebooting fixes the issue (symptomatically), so I´m affected by the bug mentioned above.
Post may be closed. Thanks again.