Mageia Bugzilla – Bug 17123
KDE sessions sometimes do not start properly, causing logout and other things to not work
Last modified: 2017-03-01 03:35:27 CET
Seemingly randomly, some KDE sessions in Mageia 5 have some quirks where some things don't work. The most obvious visual indicator of this is Klipper not running. Trying to log out of KDE does nothing, and the easiest way out at this point is Ctrl-Alt-Backspace to kill X.
Giuseppe Ghibo located a patch that he says appears to fix this issue, which I'll attach. He included the following bug URLs as references:
Steps to Reproduce:
Created attachment 7195 [details]
It might also be good to pull the latest KDE4 bugfixes from upstream (hopefully including a fix for Bug 16847 somewhere), such as:
kde-workspace 4.11.22 (from KDE Applications 15.8.0)
kdepim, kdepimlibs, kdepim-runtime 4.14.10 (from KDE Applications 15.04.3)
kdelibs 4.14.14 (from KDE Applications 15.08.3)
I doubt it's related to either of these issues, but the patch kdelibs-fix-containment.patch in kdelibs4 looks bogus.
FWIW, if one of you can reliably reproduce, could you try if something like
killall kded4; sleep 2; kded4 & disown
run as normal user works as a workaround, to obtain a normal session?
FYI, killall kded4; sleep 2; kded4 & disown doesn't give a working normal session. Note that under that conditions the command:
qdbus org.kde.ksmserver /KSMServer logout 0 0 0
hasn't any effect, as well as the shortcut keys "Ctrl+Alt+Del" which under normal session do a logout. The kmix process is also running.
With much help from Giuseppe, I have made commits to update kdelibs4 to 4.14.16 and kdebase4-workspace to 4.11.22.
Nicolas, can you:
- review my commit to updates/5/kdelibs4
- review my 2 commits to updates/5/kdebase4-workspace
- check kdelibs4/SOURCES/kdelibs-fix-containment.patch which looks bogus
We can update both of those in this bug and update the kdepim ones in another bug.
FYI, kdelibs 4.14.17 is now available upstream.
kdelibs4 4.14.18 is now checked into SVN. I was still hoping to get some feedback here, especially from Nicolas about kdelibs-fix-containment.patch, but I'll push these soon if I don't hear anything.
FWIW, running 4.14.17 and kdebase4-workspace-4.11.22 since over a month now and didn't see any issues, but somehow forgot about this, sorry. I've added a patch locally resulting from https://bugs.kde.org/show_bug.cgi?id=340915 and would like to add another one to prevent delays like reported via https://bugs.kde.org/show_bug.cgi?id=328772.
Please ping me on irc before pushing :)
Florian, please add your patches in SVN. I plan to push on Monday.
(In reply to David Walser from comment #0)
> Seemingly randomly, some KDE sessions in Mageia 5 have some quirks where
> some things don't work. The most obvious visual indicator of this is
> Klipper not running. Trying to log out of KDE does nothing, and the easiest
> way out at this point is Ctrl-Alt-Backspace to kill X.
> Giuseppe Ghibo located a patch that he says appears to fix this issue, which
> I'll attach. He included the following bug URLs as references:
> Steps to Reproduce:
This type of issue comes and goes for me, just recently it's come again.
Visible problems are that kmix doesn't start and none of the methods for KDE "Leave" menu do anything: Lock/Logout applet, right-click desktop -> Leave, or K launcher menu -> Leave.
Ctrl-Alt-Backspace ZAP reliably restores this functionality upon the new login.
Over time, I've come to create desktop icons to deal with this:
Name: killall ksmserver Command: killall ksmserver
Name: Halt Command: halt -p
which is not ideal and I've come here after searching bugzilla. On the way, I've encountered the referenced kde bug 328571, where I noticed another MGA5 user participating and some hopeful report of a patch in KDE 5.15, as I understand it: https://bugs.kde.org/show_bug.cgi?id=328571#c61
I see KDE Version 4.14.5 on my up-to-date MGA5 stable installation. Has the patch from 328571 been incorporated/can I install something to test?
Rolf, I see the exact same symptoms as you. We have something in SVN, but it hasn't been pushed to the build system. I believe Florian wanted to add a patch first. We are way overdue to get this built.
Dear David, indeed the package in http://svnweb.mageia.org/packages/updates/5/ for kdebase4-workspace-4.11.22-1 doesn't build properly (there ware a couple of glitches in the order of patches plus one patch Patch322 that need to be reworked, I did that too, and one patch that need to be removed). I've fixed and to me seems working fine. I've just to find the time to merge in the svn, as I'm just back (probably hope during this weekend). Impatient people can download kdebase4-workspace from here:
which contains already the fixed patches.
and build in the following order:
1) download from here:
and build in the following order (I found that not following these order even if BuildRequires is satisfied with older libraries at some point build fails):
1a) kdepimlibs4-4.14.10-1.mga5.src.rpm, then build and install devel binaries of it
1b) kdepim4-runtime-4.14.10-1.mga5.src.rpm, then build and install devel binaries of it, to build the next package.
1c) kdelibs4-4.14.19-1.mga5.src.rpm, then install the development libraries.
and finally build the kdebase4-workspace-4.11.22-0.3.mga5.src.rpm's packages. (I've bumped to 4.1.22-0.3, so that the official package will have 4.1.22-1.mga5 and could overlap).
This result should be like this (*beware* these are unsigned packages, so better to get the patched src.rpm and compile yourself):
I made a local repository from http://www.joeghi.com/joeghi_backports_mga5/kdepkgs.tar.gz, generated an hdlist and did
# urpmi.addmedia ghibo /download/mageia/5/201605-ghibo-kde-build/kdepkgs/RPMS/x86_64
# urpmi --no-verify-rpm --media ghibo --auto-select
That was on June 2, about 9 days ago. With a typical 2 boots every day, there has been no problem with kmix or Leave and no other new problem that I can see, FWIW.
Giuseppe, looking at the patches you swapped in/out (322-3,414-5), it doesn't look right. It should get the min UID from login.defs, but even if that's set to 1000, we need the heuristics to make it show valid normal users in the 500-999 range. It doesn't appear that will work with your changes.
I guess you must have also made some adjustments in those patches to make patch 301/416 apply, since you didn't change the actual patch. Probably the better thing to do here would be to not make any of the changes you made, but to just rediff patch 301.
I experienced this bug frequently (on more than 50% of startups) on an older system using the nvidia proprietary driver. (Much less frequently on another installation on the same hardware using the nouveau driver.)
Last weekend, I installed the packages linked to in comment#13, using a procedure similar to that described in comment#14.
I have booted/restarted this installation 2 or 3 times each day this week. There has been no recurrence of the bug and everything else seems to be working normally. So at least on this installation these packages seem to fix the bug.
Normal user UID's start at 1000 on this system and so I have not experienced the problem described in comment#15.
The updated version is in updates/testing repository for mga5.
(In reply to Giuseppe Ghibò from comment #17)
> The updated version is in updates/testing repository for mga5.
Now we need a list of the RPMs and SRPMs associated with this update.
For the SRPMs, here is:
Testing on MGA5-32 & MGA5-64 real hardware and VM
Packages updated :
I've tried about 20 times to login/logout, reboot the system.
I never got the problem, I'm using AMD hardware though.
It's OK for 32 & 64 bits but I haven't Nidvidia hardware to OK the update.
(In reply to youpburden from comment #20)
> Testing on MGA5-32 & MGA5-64 real hardware and VM
> Packages updated :
> I've tried about 20 times to login/logout, reboot the system.
> I never got the problem, I'm using AMD hardware though.
> It's OK for 32 & 64 bits but I haven't Nidvidia hardware to OK the update.
The Bug ID is about a lot of packages, I'm gonna post results package by package :
Kinfocenter : same results as before the update, no problem so far, I can see informations about hardware, system ...
For the applets, I used all of them, according to the upstream procedure, I don't find any bugs since the fixes.
For Krandr, I'm using redshift with ranrdr and it's working well, Don't know if it's enough to validate it.
For Akonadi, I installed Kmail and Korganiser to check if there's a regression, it's.
In a general way, I can't get old bugs announced as fixed in the upstream changelog.
I think it should be OK for 32 & 64 bits and pushed to updates.
I'd need someone's answe to be sure I tested it well so we can OK the whole update pack please.
Can you check also cups printing from okular? I'm actually having problems with it, but I've actually some interference with samsung (proprietary?) drivers, which refuses to continue to print when the toner is low or exausted (though it could apparently be forced to do some extra copy), and also with other USB ports, which needs to be plugged/unplugged a few times to get working properly (also for scanners with xsane, which is not kde related), so probably other problems with newer kernels or hardware in general (cables, hub usb, etc.), and thus I couldn't test properly.
Okular's printing is going fine with my HP printer.
I don't know if it's a printer problem, but xsane is working fine too so it's ok for me...
I give you detail, I'm using an ethernet plug to connect my printer to machines, I tested the update with USB and it was ok.
OK, good. that's was an hardware problem probably.
$ rpm -q kdebase4-workspace
Since https://bugs.mageia.org/show_bug.cgi?id=17123#c14 I don't have the issues of this bug, FWIW. I did remove the "ghibo" source at that time.
WRT printing, I'm using a usb-connected Brother MFCJ5620DW multifunction for printing and scanning with xsane. I use the Brother script to install the drivers. This is working fine except that I do have an occasional issue with printing from gwenview or okular in that printing a second instance without restarting the application, first, can result in the app being unresponsive and printing not happening. If I kill the app and start over, it works. If I am patient, I have had experiences that app becomes responsive and printing completes if I wait long enough. I couldn't say when this glitch started happening. User reviews of this machine include reports of it being slow to initiate printing.
Probably is not related to kde, but seems some printing problem is around. Maybe due to some cups upgrade? IMHO worthwhile to open also a new bug report about this printing problems. Downgrading to pre-kde upgrade stuff would still have those problems?
I haven't installed these packages and I have the problem with okular freezing when printing sometimes.
Ok, so it's definitevely another bug.
Sometimes (for months) on my laptop i can not log out the normal way - like described above.
And sometimes i after resume from suspend see a message "ksmserver krashed" but it seem not related, just now i saw that message but could still logout using the menu.
Current cauldron, Plasma5.8.5-2, nvidia340-340.101-2, kernel4.9.0-3
BTW, could Bug 20029 be the same as this bug?
No, I think Plasma5 login/logout problems is unrelated to this as the code basis (apart kdelibs 4.14.26 of KDE4, and 4.14.27 of Plasma5) is pretty different.
BTW, could we also clean the mga5_testing repository? Many packages of this bug are built there, using also other libraries in the same media source (printing, etc.) which are not part of updates, so when moving to updates IMHO could result a mess (or better to build using the upgrade repository only) because of different built libraries.
We still have gotten nowhere on this, and now have a security issue to fix (kdelibs4 4.14.30):
I've not had this bug since last June, when I upgraded packages from Ghibo's tarball, https://bugs.mageia.org/show_bug.cgi?id=17123#c14
However, there might have been a side effect as a result that I'm not smart enough to determine.
When I build Sachesi: https://github.com/xsacha/Sachesi I have to use the qt4 version of qmake:
$ sudo update-alternatives --config qmake
There are 2 programs which provide `qmake'.
+ 1 /usr/lib64/qt4/bin/qmake
* 2 /usr/lib64/qt5/bin/qmake
Enter to keep the default[*], or type selection number: ^C
When I run it, I get an error that I have had no luck solving:
Cannot mix incompatible Qt library (version 0x50201) with this library (version 0x50402)
The Sachesi executable does run without such an error on ROSA Desktop Fresh R8 release 2014.1 for x86_64, in case there is some relation.