KDE5 randomly 'loses' Reboot and Shutdown from launcher menu

[rawthey]

I'm running FreeBSD 11,2-RELEASE-p3, kde5-5.12.5.18.08.1 and sddm-0.17.0_2

In System Settings -> Workspace -> Startup and Shutdown -> Desktop session I have 'Offer shutdown options' checked so I normally see the Reboot and Shutdown options in the Leave tab of the launcher. But they sometimes vanish and eventually reappear in subsequent sessions. The last time this happened they failed to return after logging back in but did reappear after a reboot as shown in the screenshots below.

The only significant thing I've noticed that might be relevant is the following messages on the system console during the session with the missing options.

Oct 20 10:44:31 curlew console-kit-daemon[768]: CRITICAL: ck_session_set_active: assertion 'CK_IS_SESSION (session)' failed
Oct 20 10:45:25 curlew ck-launch-session: error connecting to ConsoleKit

 

[aht0]

Is it the same using alternative launchers? Plasma5 has options for several. I haven't noticed that issue using "traditional Win98/2000/ME-like" launcher - whatever it's called there.

 

[rawthey]

Is it the same using alternative launchers? Plasma5 has options for several. I haven't noticed that issue using "traditional Win98/2000/ME-like" launcher - whatever it's called there.

I assume you're meaning the 'Application Menu' widget - 'A launcher based on cascading menus'

I've added it to the taskbar as an extra launcher and will wait until next time the problem crops up so I can see if it affects both. Sod's law being what it is I expect it might be some time before it happens again now that I have something in place to make a comparison with

 

[aht0]

Yes, it's exactly what I meant. I just could not recall it's name and browsed this forum from Windows machine so I could not just look it up in a few seconds.

 

[rawthey]

The problem returned again today - no shutdown or reboot options in either version of the launcher.

Once again I got the console-kit error messages on the console. These messages only seem to appear when the shutdown and reboot options are missing so it looks like it's some sort of console-kit related issue.

 

[Vull]

ConsoleKit seems to be part of the dbus implementation. To get the reboot and shutdown buttons to appear, I had to put dbus_enable="YES" in my /etc/rc.conf file. I was previously able to launch kde5 okay without dbus being enabled, and everything looked okay at first, but I too was missing the shutdown and reboot buttons. There is also a recommended syntax for the user account's $HOME/.xinitrc file, which is:

ck-launch-session dbus-launch --exit-with-session /usr/local/bin/startkde

This might or might not be necessary using sddm but I'm using it. Sddm does seem to be the recommended window manager for kde5, and kdm_enable="YES" doesn't seem to be supported anymore, as I deduced after several unsuccessful tries hah

 

[drhowarddrfine]

Loses is spelled l-o-s-e-s

 

[rawthey]

ConsoleKit seems to be part of the dbus implementation. To get the reboot and shutdown buttons to appear, I had to put dbus_enable="YES" in my /etc/rc.conf file. I was previously able to launch kde5 okay without dbus being enabled, and everything looked okay at first, but I too was missing the shutdown and reboot buttons. There is also a recommended syntax for the user account's $HOME/.xinitrc file, which is:

ck-launch-session dbus-launch --exit-with-session /usr/local/bin/startkde

This might or might not be necessary using sddm but I'm using it. Sddm does seem to be the recommended window manager for kde5, and kdm_enable="YES" doesn't seem to be supported anymore, as I deduced after several unsuccessful tries hah

Yes, I'm using dbus and sddm and it works most times apart from apparently random failures when I don't see Shutdown or Reboot in the launcher. When that happens I click Logout and fall back to sddm which also no longer has the usual Shutdown and Reboot options. It's the randomness of this that's my main concern. It implies an instability somewhere in KDE rather than some configuration issue.

Fortunately I haven't seen the problem since I upgraded to kde5-5.12.7.18.08.3 about a week ago so I'm keeping my fingers crossed hoping that the problem has gone away.

 

[Vull]

I've put KDE version 5.12.5.18.08.1 on several test installs of FreeBSD 11.2-RELEASE-p4 and one 12.0-RC1 install, using an old Dell Dimension 4700 i386 machine for the tests, without experiencing the random problem you describe, which I hope might ease your concerns a bit.

Before I even install sddm I initially just install xorg and kde5, and then start a few test X sessions from my lower level user account, by running startx from an ssh login session on my laptop. This makes it easy to read all the error messages and other messages sent by KDE to the terminal session on my laptop. What I'm inferring from these messages is that both KDE in general, and the dolphin file manager program in particular, still contain code that expects HAL to be running, and they either take a fallback measure or experience minor (non-fatal) failures when they can't find it running. From this I'm guessing that they are still in the process of weeding HAL dependencies out of this code, and have as yet been only partially successful at reducing some of these dependencies and their consequences. I think this is still an ongoing battle for kde5 because a lot of the code is pretty old, and because there is so much of it (with over 700 packages included in the pkg install xorg kde5 combination).

If I then enable the HAL daemon with hald_enable="YES", most of my bigger problems go away, but then I'm stuck with a system that depends on /usr/local/sbind/hald, which is deprecated. Furthermore, once I've used HAL even once, the overall system seems to remember that it's there and starts behaving differently, even after I disable HAL. This also seems to happen if I use autofs_enable="YES", and then try to back out the changes - the system starts behaving differently and I can't seem to quite get it back to its original state. This is the main reason for all these test installs.

As a temporary workaround in expectation of future KDE improvements, I'm presently avoiding the HAL dependencies and my autofs configuration problems by mounting usb thumb drives by hand, using the mount command, and living with D-Bus only, since D-Bus is not yet deprecated, arguably shouldn't be, and presumably won't be any time soon.

To mount a usb drive by hand, in a way that makes the drive writable by my user account, and avoids permission errors during dolphin's copy operations, I use sudo mount -t msdosfs -o u=$USER /dev/da0s1 /home/$USER/usb1 or sudo mount -t msdosfs -o large,-u=$USER /dev/da0s2 /home/$USER/usb2 for my 1TB usb drive. Had to create the mount directories in advance using mkdir from my user account to get the file permissions right. I have to end the dolphin session before I can unmount either drive, using, for example, sudo umount /dev/da0s1. Otherwise, it tells me the drive is busy and fails to unmount it.

Starting with FreeBSD 12.0 the -o large option is thankfully no longer usable or necessary, which lets us use the exact same mount command syntax for all msdos fat32 filesystem drives regardless of size.

 

[zirias@]

Since the latest upgrade, I have the same problem on one of my two machines with kde desktop. I found it works after I manually stopped the running console-kit-daemon. Logging in from sddm launches a new instance and this one seems to always work.

So my workaround for now is killing console-kit-daemon when sddm is started by creating the file /etc/rc.conf.d/sddm with just the line killall console-kit-daemon. Works so far.

Of course, if anyone knows what could be the root cause for the problem, this would still be quite nice.

 

[Vull]

Since the latest upgrade, I have the same problem on one of my two machines with kde desktop. I found it works after I manually stopped the running console-kit-daemon. Logging in from sddm launches a new instance and this one seems to always work.

So my workaround for now is killing console-kit-daemon when sddm is started by creating the file /etc/rc.conf.d/sddm with just the line killall console-kit-daemon. Works so far.

Of course, if anyone knows what could be the root cause for the problem, this would still be quite nice.

Likewise I had recurring problems with sddm, so, at some time since last November, I quit using it altogether, and instead I'm just starting the desktop sessions using startx. This allows me to shutdown or reboot cleanly from the kde desktop, and also cuts down substantially on CPU and memory usage when the desktop is not being used at all, or after logging out of the desktop. IMO sddm is perhaps the root case of the problem. I've considered installing lightdm as an alternative, but haven't tried it yet. For my purposes abandoning the use of any graphical login manager whatsoever has been the best solution. Your mileage may vary.

As a general guideline.... I personally setup my systems to force clean all "tmp" dir (usually /tmp and /var/tmp) on shutdown.
I have experienced random issues in various desktop environment linked to the fact that "tmp" kept obsolete infos of former "X" sessions.

You can make a try to define if "tmp" is the culprit.
Reboot ang log in in single user mode, mount all partitions.
Clean the tmp directories.

in single user mode :

mount -a
cd /tmp
rm -rf *
rm -rf .*

cd /var/tmp
rm -rf *
rm -rf .*

In my systems, I try to centralized all "tmp" in a unique directory in /.
In /var, I set a soft link: ln -s ../tmp /var/tmp

Reboot all and launch KDE

I don't know if this will solve your problem, but this remains a good guideline to solve some strange and random behaviors.
One should setup a full "tmp" cleaning" when shutting down the station. It is difficult to set it up on reboot because "tmp" is already used by the system at an early reboot stage, except in single user mode.

NOTE :
- There is a standard macro /etc/rc.d/cleartmp which can be called on boot, but it makes a selective cleaning preserving some X11 related files accross reboot. Sometimes, theses X11 files are obsolete and must be force cleaned.
- Auto "tmp" cleaning must be deactivated when upgrading the OS. The system updates itself following several reboot and so keep essentials info in /tmp accross reboot. I setup a full "tmp" cleaning in a special macro that I deactivate when doing an upgrade

Just having clear_tmp_enable="YES" in /etc/rc.conf seems to do the trick for me. The only thing I ever find in /var/tmp after reboot is a vi.recover file, which seems harmless enough, so I just leave it there.