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 |
:-) :-) |