Created attachment 11911 [details] Zombies process belonging to startplasma-x11 startplasma-x11 seems to spawn process that become zombie after opening session. These process are: - 50-systemd-user - xdg-user-dirs-gtk - s2u - qt5-check-opengl See attached screenshot. Assigning to KDE Team. CC'ed recent commiter.
Blocks: (none) => 17523
Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Still the case in M8 Beta 2 Default installation with Plasma. Classic ISO.
Source RPM: plasma-workspace-5.19.5-1.mga8.src.rpm => plasma-workspace-5.20.4-1.mga8.src.rpm
Ping QA on this. Am I still the only one to see this? I CAN reproduce it on every VM/baremetal installs from M8 Classic ISO.
Source RPM: plasma-workspace-5.20.4-1.mga8.src.rpm => plasma-workspace-5.20.4-4.mga8.src.rpmSeverity: normal => majorPriority: Normal => High
I'm seeing it, from a newly-installed system on a Probook 6550b. When I looked at Ksysguard right after the boot, I saw five zombies, but as I was studying it, one of them seemed to disappear. The s2u process was one of the four that remained.
CC: (none) => andrewsfarm
Created attachment 12218 [details] screenshot of TJ's Ksysguard Note that the s2u process is listed twice, once under sddm, and once on its own.
I think those processes are started by the scripts in /etc/X11/xinit.d. Which display manager are you using? (GDM, SDDM, LightDM, etc) Does the problem happen in GNOME or IceWM? Does the problem happen if you log in from a different display manager?
CC: (none) => luigiwalser
It happens in run level 3 (using startx startplasma-x11) as well, so it is not caused by the dm. Looking at plasma-workspace, I'm wondering about https://svnweb.mageia.org/packages/cauldron/plasma-workspace/current/SOURCES/plasma-workspace-5.13.4-remove-XDG_DATA_DIRS.patch?revision=1251947&view=markup&pathrev=1448129 as startkde was renamed to startplasma-x11, not removed.
CC: (none) => davidwhodgins
i don't understand your last sentence at all.
Me neither. Maybe he pasted the wrong link?
The comment indicates that patch was dropped as startkde was removed. startkde was renamed to startplasma-x11, not removed. Should the patch have been changed to apply to startplasma-x11 instead of being removed? If that's not correct, or not relevant to the zombie process problem, just ignore that comment. I'm just looking to try and figure out what changed in plasma-workspace between Mageia 7 and 8 to cause the zombie processes. It's something in startplasma-x11 that's causing the zombies.
I think we should raise the priority of this bug as it seems plaguing plasma5, and place it in a "clumsy" and unstable mode. The problems arise not only on sddm, but also on lightdm and I guess any other DMs. Using ctrl-alt-backspace zapping, and then logging in again would trigger the problem: the next plasma5 startup is blocked at the "progress bar" stage: after a minute you hear the sound startup, and then after some further minutes the desktop completes the startup. The same problems also arise from a simple logout, not just the ctrl-alt-backspace zapping. Also just not using any DM at all, e.g. to reproduce, go in level 3 (init 3 from a console), then edit $HOME/.xinitrc and place there just the line /usr/bin/startkde. At every ctrl-alt-backspace zapping a certain amount of plasma5 process still doesn't terminate after the Xorg process is exited (e.g. kwin_x11, etc.). Could be kwin_x11 the root of the problem? I don't think it's related to hardware as it was spotted on intel chipsets, nvidia and even in a virtualbox virtual machine. Many processes also crashes. I think we could trigger the segfaults enabling the core dumping in sysctl, and then analizing the core dumps generated after we install the corresponding debug packages.
CC: (none) => ghibomgx
There are also extra infos here: https://bugs.mageia.org/show_bug.cgi?id=27147
(In reply to Giuseppe Ghibò from comment #11) > I think we should raise the priority of this bug as it seems plaguing > plasma5, and place it in a "clumsy" and unstable mode. So added to errata in a simple way, for now.
CC: (none) => friKeywords: (none) => IN_ERRATA8
According to comment #10, it seems that from plasma in MGA7 to plasma in MGA8 we did the following change: 1) use /usr/bin/startplasma-x11 as plasma startup script 2) add a soft link /usr/bin/startkde -> /usr/bin/startplasma-x11. What changed is that also the original /usr/bin/startkde in MGA7 was a script (and startplasma-x11 was not existing yet), while in MGA8 /usr/bin/startplasma-x11 is a binary executable, compiled from c++ sources. The original "startkde" script was having the following extra cleanup commands: echo 'startkde: Shutting down...' 1>&2 # just in case test -n "$ksplash_pid" && kill "$ksplash_pid" 2>/dev/null # Clean up kdeinit5_shutdown unset KDE_FULL_SESSION xprop -root -remove KDE_FULL_SESSION unset KDE_SESSION_VERSION xprop -root -remove KDE_SESSION_VERSION unset KDE_SESSION_UID echo 'startkde: Done.' 1>&2 but apparently the C++ code of startplasma-x11 is doing a similar cleanup procedure, see (https://github.com/KDE/plasma-workspace/blob/e25308e163a33970ba695860e53cdb6fc292796b/startkde/startplasma-x11.cpp#L113) seems using a similar procedure.
not sure if this is the same bug but similar to (In reply to Giuseppe Ghibò from comment #11) > Using ctrl-alt-backspace zapping, and then logging in again would > trigger the problem: the next plasma5 startup is blocked at the "progress > bar" stage: after a minute you hear the sound startup, and then after some > further minutes the desktop completes the startup. not sure if this is the same bug. same as above, then, after 2 or 3 logout/in Plasma does not present DE, just represents greeter (SDDM in this case)
CC: (none) => westel
FYI the problem above occurs even without any DM, e.g. you can switch from console to init level 3, doing: init 3 then login from console (plain user, not root), edit the file: $HOME/.xinitrc and add there /usr/bin/startkde or /usr/bin/startplasma-x11 then run startx. At the next restart (or after a certain number of restarts, usually within 5-6) you should hit the problem: the plasma session is stuck at the splash screen for several minutes (1-2). You can also disable the splash with some config, but doesn't change much the behaviour, because some of the processes from the previous session are still there. What you describe I got recently once, but after a kernel resume, after it was suspended/sleep from plasma (basically you get a new login session instead of the older one).