Bug 27362 - startplasma-x11 spawns zombie process
Summary: startplasma-x11 spawns zombie process
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: Mageia 8
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard:
Keywords: IN_ERRATA8
Depends on:
Blocks: 17523
  Show dependency treegraph
 
Reported: 2020-10-05 18:41 CEST by Aurelien Oudelet
Modified: 2021-02-19 08:57 CET (History)
8 users (show)

See Also:
Source RPM: plasma-workspace-5.20.4-4.mga8.src.rpm
CVE:
Status comment:


Attachments
Zombies process belonging to startplasma-x11 (250.35 KB, image/png)
2020-10-05 18:41 CEST, Aurelien Oudelet
Details
screenshot of TJ's Ksysguard (157.50 KB, image/jpeg)
2021-01-15 16:28 CET, Thomas Andrews
Details

Description Aurelien Oudelet 2020-10-05 18:41:23 CEST
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.
Aurelien Oudelet 2020-10-29 16:13:22 CET

Blocks: (none) => 17523

Comment 1 Aurelien Oudelet 2020-10-29 16:15:18 CET
Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)
Comment 2 Aurelien Oudelet 2020-12-14 15:16:30 CET
Still the case in M8 Beta 2 Default installation with Plasma. Classic ISO.
Aurelien Oudelet 2020-12-14 15:16:40 CET

Source RPM: plasma-workspace-5.19.5-1.mga8.src.rpm => plasma-workspace-5.20.4-1.mga8.src.rpm

Comment 3 Aurelien Oudelet 2021-01-15 14:19:07 CET
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.rpm
Severity: normal => major
Priority: Normal => High

Comment 4 Thomas Andrews 2021-01-15 15:49:52 CET
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

Comment 5 Thomas Andrews 2021-01-15 16:28:00 CET
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.
Comment 6 David Walser 2021-01-15 17:18:49 CET
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

Comment 7 Dave Hodgins 2021-01-15 17:30:03 CET
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

Comment 8 Nicolas Lécureuil 2021-01-15 20:24:16 CET
i don't understand your last sentence at all.
Comment 9 David Walser 2021-01-15 20:43:21 CET
Me neither.  Maybe he pasted the wrong link?
Comment 10 Dave Hodgins 2021-01-15 20:47:35 CET
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.
Comment 11 Giuseppe Ghibò 2021-01-30 11:36:45 CET
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

Comment 12 Giuseppe Ghibò 2021-02-01 16:28:27 CET
There are also extra infos here: https://bugs.mageia.org/show_bug.cgi?id=27147
Comment 13 Morgan Leijström 2021-02-05 20:44:16 CET
(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) => fri
Keywords: (none) => IN_ERRATA8

Comment 14 Giuseppe Ghibò 2021-02-16 19:34:50 CET
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.
Comment 15 ben mcmonagle 2021-02-19 08:22:58 CET
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

Comment 16 Giuseppe Ghibò 2021-02-19 08:57:13 CET
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).

Note You need to log in before you can comment on or make changes to this bug.