Description of problem: My wife suddenly developed a weird behaviour of X where no window had titlebar/border. I eventually traced this down to kwin_x11 not running. This behaviour survived numerous restarts of her X. This behaviour was true on at least 2 machines onto which her home directory was nfs mounted. Other users(eg, me) had no such problem. Comparing her .config/ksmserverrc to mine, we both had program1=/usr/bin/kwin_x11 under [Session: saved at previous logout] but she had restartCommand1= while I had restartCommand1=/usr/bin/kwin_x11,-session,10dfdeded2000153379701100000029210004_1591029939_826251 Looking in an old backup of her home, I putrestartCommand1=/usr/bin/kwin_x11, into hers restartCommand1=/usr/bin/kwin_x11,-session,10dfdeded2000153493426300000299520005_1598028942_456375 This seemed to solve the problem. a) I suspect that much less than 1% of Mageia users would have known how to solve this problem. b) setting up a new test user, the both the lines program1=... and restartCommand1=... were not there, but it started up with kwin_x11 running and the windows behaving properly. Note that NoBorders was not selected for her in SystemSettings->ApplicationStyle->WindowDecarations->BorderSize and changing Bordersize to some other option made no difference. Also Alt-F3 did not bring up a menu (presumably because kwin_x11 was not running) So two questions: What caused kwin_x11 to die? (probably impossible to answer at this point) Why, when X was restarted (with alt-ctrl-Bksp twice and then relogging in from sddm login), why did kwin_x11 not restart? Note that without a title bar, there are many GUI programs that cannot be stopped (eg, SystemSettings and Zoom are two examples we ran into) Again, this is a situation that almost all users would be unable to extricate themselves and thus should not arise. How reproducible: I am not going to try and I have no idea why kwin_disappeared so cannot reproduce.
Hi, thanks reporting this strange behaviour. In facts, have your wife switched user : Start session 1 user A, no logout, start session 2 user B ? Does she log out / log in several times without restarting PC? Does this look like this: https://bugs.mageia.org/show_bug.cgi?id=27147
CC: (none) => ouaurelien
No, it does not look like this. Her system is set up not to go to sleep, although it goes into screenlock, and the screen shuts off. The system displayed the desktop fine, just every program openened in a window had no titlebar/border, and no way of moving the window (alt F3 did nothing except typed R on the line if doing this with a Konsole window) kwin_x11 was not running. The programs worked-- ie, I could use the menus on the menu bar, use Konsole, run Zoom, look at pictures, but with no titlebar, could not move anything, every window put itself onto the top left of the screen (ie one on top of the other, and with no way of moving them, made multiple windows pretty useless). This persisted on logout/login. 27147 seems to be a problem with sddm itself, while this seems to have been a problem with ksmserver not starting kwin_x11. As soon as I managed to get it to start kwin_x11 (either by doing kwin_x11 --replace, or adding that line in ksmserverrc), all problems disappeared. Yes, the machine is left on and running always, and she does logout/login without rebooting. We did have to reboot a few days ago, but this problem was not there immediately afterwards, but a couple of days later.
(In reply to w unruh from comment #2) > > Yes, the machine is left on and running always, and she does logout/login > without rebooting. We did have to reboot a few days ago, but this problem > was not there immediately afterwards, but a couple of days later. So it is similar behaviour I see in bug 27147. I suspect first session opened and later closed to be not fully closed exactly. When such behaviour repeats, can you try loginctl in a console and see if there is some session not fully closed?
Assignee: bugsquad => kde
CC: ouaurelien => (none)
Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. We should have output of inxi command (urpmi inxi before) $ inxi -SGxx Closing as OLD.
Resolution: (none) => OLDCC: (none) => ouaurelienStatus: NEW => RESOLVED