Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Consolekit and elogind switch questions
Date: Fri, 20 Dec 2019 00:53:48
Message-Id: 3d53e26c-54c1-3afa-040d-df50be452a67@gmail.com
In Reply to: Re: [gentoo-user] Consolekit and elogind switch questions by Mick
1 Mick wrote:
2 > On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
3 >> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
4 >>> Thanks much for the info. Maybe the switch will go well for me too.
5 >> If it works for you it will be good news for the rest of us ;-)
6 > If hald's list of devices has anything to do with it, Dale is bound to nail it
7 > on the first (re)boot! :-)
8 >
9 > The consolekit framework is responsible switching between users on a system.
10 > As I understand it, when you go to 'Plasma/Leave/Switch User' menu option,
11 > console kit daemon is responsible for:
12 >
13 > 1. Looking at PAM and any processes you own as a user in a login session.
14 > 2. Checking which seat (local or remote) you are logged in as and associating
15 > the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.).
16 > 3. Connecting to the d-bus system bus to manage the local login session and
17 > pass control of hardware devices to the new user.
18 > 4. When the new user enters their credentials at the Display Manager, check
19 > with PAM what processes the new user is authorised to access/use in their
20 > login session.
21 >
22 > I should have the above mostly correct. You may ask if any of this control
23 > framework complexity is *necessary* for a single user called Dale, who won't
24 > allow anyone else to take his 'seat' at the PC without a fight. The answer is
25 > probably no, and this is why simpler desktop environments like *box,
26 > Enlightenment, etc. do not offer the facility to switch users and therefore do
27 > not ultimately need consolekit.
28 >
29 > There are no screenshots of consolekit/elogind because AFAIK neither offer a
30 > GUI application. However, when you run 'ck-list-sessions' in a terminal
31 > you'll see your local session, as well as any other login sessions you may be
32 > running at the time, e.g. /dev/tt1, remote logins over ssh and which of these
33 > are active at the time.
34 >
35 > Since consolekit is no longer under development and systemd appears to have
36 > taken over most of the Linux distros, elogind is the current service which can
37 > run as stand alone on openrc (just as udev of systemd does).
38 >
39 > When elogind is running you can use 'loginctl list-sessions' in a terminal to
40 > see who's running a session. The man page gives more options.
41 >
42 > You don't *have* to add elogind as a boot service, because any applications
43 > which need it will launch it themselves. However, don't be surprised if some
44 > desktop functions are not working as expected. For example, the SDDM Display
45 > Manager's shutdown/reboot buttons may not be displayed and even if they are
46 > displayed they'll do nothing when you click on them after a reboot. If after
47 > a reboot you login/out into your Plasma desktop, then elogind will be running
48 > and the SDDM buttons should function again normally.
49 >
50 > I have converted a number of systems to elogind. It should be as easy as
51 > setting in your make.conf:
52 >
53 > USE="elogind -consolekit"
54 >
55 > grep consolekit -r /etc/portage
56 >
57 > to find and remove/replace any USE flags still asking for consolekit to be
58 > emerged. Then,
59 >
60 > emerge --depclean -v -a consolekit
61 >
62 > emerge -uaNDv @world
63 >
64 > emerge @preserved-rebuild -v -a
65 >
66 > rc-update del consolekit
67 > rc-update add elogind boot
68 >
69 > reboot
70 >
71 > >From memory that's all there is to it.
72
73
74 I just switched.  I kept forgetting to do this when the puter was
75 actually idle.  Anyway, I changed the USE flags and did a emerge -uaDN
76 world which updated/installed as new several packages and took about 30
77 minutes on my rig.  Once that was done, I went to the boot runlevel and
78 used the old checkrestart to see what needed restarting.  Sadly, the
79 init process, process #1, was in the list.  While everything went well
80 enough, so it seems anyway, I'm adding the reply to say this.  It seems
81 one does have to reboot. 
82
83 So, if anyone runs up on this thread, be ready for a reboot.  I'm not
84 sure what it is that made init need a restart but that's what it showed
85 and I've never seen it listed before. 
86
87 Thanks to all, Mick for sure since he posted a general guide, for the help.
88
89 Dale
90
91 :-)  :-)