Bug 18942 - sddm create an "abandoned" session due to dbus --autolaunch
Summary: sddm create an "abandoned" session due to dbus --autolaunch
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-14 14:06 CEST by Chris Denice
Modified: 2020-08-20 11:18 CEST (History)
6 users (show)

See Also:
Source RPM: sddm-0.13.0-4.mga6.src.rpm
CVE:
Status comment:


Attachments

Description Chris Denice 2016-07-14 14:06:44 CEST
Using sddm, login into a (preferably light) window manager and enter:

loginctl

you'll get:

> loginctl
   SESSION        UID USER             SEAT
       c11        958 sddm             seat0
       c12       1000 you              seat0

Session c11 here should not be closed:

>loginctl session-status c11

returns:

State: closing
       Unit: session-c11.scope
                  ââ26557 dbus-launch --autolaunch  b524af88b4fb6821f6a8a1a765167 
                  ââ26558 /usr/bin/dbus-daemon --fork --print-pid 5 

and this is dbus-launch --auto-launch which is causing the hang.

> systemctl

shows that, indeed, the session is "abandoned":

session-c11.scope loaded active abandoned Session c11 of user sddm


It is not clear to me why dbus-launch is started with the option --autolaunch, and if it is started by sddm or by our wrapper around it. The man of dbus-launch discourages to do so:

"The --autolaunch option is considered an internal implementation detail of libdbus, and in fact there are plans to change it. There's no real reason to use it outside of the libdbus implementation anyhow".

I am investigating, but any help would be welcome. I already reported this issue a while ago upstream, they do not give a s..., unfortunately.

Cheers,
Chris.
Comment 1 Chris Denice 2016-07-14 14:07:41 CEST
Arg, made a very unfortunate typo: I meant "Session c11 here should BE closed".
Marja Van Waes 2016-07-14 15:40:57 CEST

CC: (none) => marja11
Assignee: bugsquad => mageia

David Walser 2016-07-22 15:40:46 CEST

CC: (none) => doktor5000

Samuel Verschelde 2016-08-25 16:23:17 CEST

Assignee: mageia => kde

Comment 2 Chris Denice 2016-11-08 09:26:31 CET
Added Neil as CC, he may have an idea from his fedora experience and all the DM started with systemd services ;)

CC: (none) => ngompa13

Comment 3 Chris Denice 2016-11-24 16:47:23 CET
Workaround here:

https://bugs.mageia.org/show_bug.cgi?id=19821#c1
Comment 4 Nicolas Lécureuil 2017-03-15 16:04:18 CET
is it still valid on current cauldron ?

CC: (none) => mageia

Comment 5 Chris Denice 2017-03-16 14:59:00 CET
Yes it is. Reported upstream, they do not give a shit, as for the other bugs.

I am convinced sddm sucks and the developers do not understand systemd. Even "xdm" works better. They please themselves ringing bells and making dirt shinning, but at the end, counting users and not pulling mess into the login sessions is too difficult for them.
We should move to lightdm, that's a personal opinion of course, but supported by facts.

Cheers,
chris.
Comment 6 Hoyt Duff 2017-04-16 22:08:49 CEST
I noticed just last week that when the sddm package is deleted, sddm leaves it's entry in /etc/group.

CC: (none) => hoytduff

Comment 7 Aurelien Oudelet 2020-08-20 11:18:57 CEST
As of today in Cauldron, sddm version is sddm-0.18.1-4.mga8 and every sddm.user.slice are correctly ended when user log on to desktop env.

loginctl reports:
[aurelien@mageia ~]$ loginctl
SESSION  UID USER     SEAT  TTY
     c2 1000 aurelien seat0

So, no longer exists in Cauldron.

CC: (none) => ouaurelien
Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.