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.

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
Priority: Normal => High
Severity: normal => major

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) => fri
Keywords: (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).

OK, I've identified part of the problems. 

Actually the problems are two: 1st the zombie processes, 2nd the timeout for 2nd and subsequents times plasma session is (re)started. Apparently they are not related, though fixing the zombie processes might also mitigate or cleanup the configuration for further analysis.

Plasma needs to be restarted in one of the following cases:

1) through a "clean" logout of a plasma session. At this point the "X" process (and all its childs) is terminated and the greeting screen from sddm (or whatever other display manager) is shown again.

2) when the "X" process is "zapped" through ctrl-alt-backspace-backspace (in
virtualbox this can be simulated with "right ctrl"-backspace-backspace.

3) in a session exited in one of 1) or 2) cases, but without a display
manager. In this case the desktop session is started the first time through startx, and the startup command placed in $HOME/.xinitrc.

I identified the processes listed as "defunct" with "ps" as being generated by an "improper" way the xinit scripts are called.

Actually the xinit scripts, i.e. the scripts run before starting plasma (or
gnome) are run from the directories:

	/etc/X11/xinit.d/* and /etc/X11/xinit/xinitrc.d/*

in the alphabetical order. There are two ways of running those scripts:

a) in background. I.e. the script is run as:

 <script> &

b) sourced. I.e. the script is run as:

 . <script>

from the parent starting session script, where "." is the "source" command of
bash. Basically running as "source" it's like having the content of the
script "pasted" in the main parent script, so "variables" and thus "exits" are exposed. This means that if a script running as source contains "exit 0", the parent script is terminated. Viceversa an "exit 0" in a script ran in background terminates only that script.

The xinit scripts are run either in background (with &) or sourced, according to whether they have or not the comment line:

	# to be sourced

if they have, the scripts are "sourced", otherwise, they are run in backgrounds.

Now when a script is run in background spawns other processes which are
already a "daemon", i.e. they fork and exits, the whole script become "defunct".
It's better those script are run as sourced, rather than in background. Those are for instance /etc/X11/xinit.d/s2u,
/etc/X11/xinit/xinitrc.d/98-vboxcllient.sh, /etc/X11/xinit/xinitrc.d/50-systemd-user.sh
and many others.

Exists also a little part of the problem due to the session name change
(from startkde to startplasma-x11); actually session name might be "startplasma-x11" or "Plasma", or even with the full path, like "/usr/bin/startplasma-x11".

BTW, sometimes there is also the "ionice" process shown as defunct. This is
generated by mgaapplet. A way of fixing this is by replacing the line:

	run_program::raw({ detach => 1 }, 'ionice', '-p', $$, '-n7');

of line 260, with:

	run_program::raw({ detach => 0 }, 'ionice', '-p', $$, '-n7');


I've fixed all the scripts in a test with COPR here:

https://copr.fedorainfracloud.org/coprs/ghibo/mga8-xinit-fixed/

and effectively, the defunct processes are disappeared. People willing to try
have just to enable the copr "ghibo/mga8-xinit-fixed", or wait they are
properly proposed in updates_testing.

Is that enough for having the plasma session multiple startup without timeouts? Actually it doesn't. Nor even cauldrons' plasma 5.21. It mitigates, but I've verified, and this is exposed especially running mga8 under virtualbox that, within 5 or 6 quick attempts, if you do multiple X11 zapping with "right ctrl"-backspace-backspace, the "kwin_x11" process often remains in the background, leaving file locks around even after X11 is terminated, and interferes with subsequent session restarting, which goes in timeout for some minutes. This of course wasn't happening on mga7 with plasma 5.15, where you can zap X11 as many times as you want, without obtaining those extra timeouts.

Looking at the plasma 5.20 and subsequents code, the startup way from 5.15
to 5.20 was changed from a script named /usr/bin/startkde to a binary executable named /usr/bin/startplasma-x11. It's not just a matter of name change, as we provide soft links /usr/bin/startkde -> /usr/bin/startplasma-x11 for
 backward compatibility, but the code changed from a bash script to .cpp code, which, in theory, should do the same stuff. Here is the code change:

plasma 5.15 (bash script)
https://github.com/KDE/plasma-workspace/blob/00f52862a7b44fb6c960f9b13452b60254940c0a/startkde/startkde.cmake#L8

plasma 5.20 (c++ code)
https://github.com/KDE/plasma-workspace/blob/30a070c653ce09c635d622439d7dd9d71e82d52c/startkde/startplasma-x11.cpp#L36

apparently both codes are ignoring the SIGHUP from X server termination, and have their own process cleanup.

(In reply to Giuseppe Ghibò from comment #17)
> OK, I've identified part of the problems. 
> 
This is an awesome wisdom and Sherlock Holme-like investigation.

Note, that on Cauldron, these zombies process are still there even when Plasma (x11) starts with version 5.21.1 of Plasma.

Note also that this only affects Plasma X11 session.

Doing a test in a VM, in Cauldron with latest Wayland-stuff from Plasma:
no Zombies processes belonging to a startplasma binary.
Because, this is Wayland session.


The only Zombie one is a "ionice" spawned by mgaapplet UNTIL it goes online to look for updates. As long as updates are checked, this Zombie one vanishes.

> Note also that this only affects Plasma X11 session.
> 
> Doing a test in a VM, in Cauldron with latest Wayland-stuff from Plasma:
> no Zombies processes belonging to a startplasma binary.
> Because, this is Wayland session.
> 
> 
> The only Zombie one is a "ionice" spawned by mgaapplet UNTIL it goes online
> to look for updates. As long as updates are checked, this Zombie one
> vanishes.

The defunct processes of comment https://bugs.mageia.org/show_bug.cgi?id=27362#c0 happens also on Gnome, I saw them, together with some other, like 98-vboxclient.sh, at least if you are running inside a virtualbox VM and with virtualbox-guest-additions installed. You can get rid of them installing the packages of 

https://copr.fedorainfracloud.org/coprs/ghibo/mga8-xinit-fixed/

with dnf, or one by one, with urpmi, seeking for the packages on the repo, e.g.:

https://download.copr.fedorainfracloud.org/results/ghibo/mga8-xinit-fixed/mageia-8-x86_64/02043702-xdg-user-dirs-gtk/xdg-user-dirs-gtk-0.10-8.1.mga8.x86_64.rpm or for mgaapplet https://download.copr.fedorainfracloud.org/results/ghibo/mga8-xinit-fixed/mageia-8-x86_64/02043692-mgaonline/mgaonline-3.31-1.1.mga8.noarch.rpm etc,

The stuck on the progress bar instead happens only on Plasma X11.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0197.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

This bug has been closed, however only virtualbox has been fixed for mga8, with respect to zombies. All the other packages showing the same problems needs to be backported from cauldron to mga8, where this bug was fixed. The packages, other than virtualbox, are:

desktop-common-data
libcanberra
mgaonline
msec
numlock
pulseaudio
qtbase5
s2u
systemd
xdg-compliance
xdg-user-dirs-gtk
xinitrc

I reopen, so to let all the other packages to be backfixed.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

(In reply to Giuseppe Ghibò from comment #22)
> This bug has been closed, however only virtualbox has been fixed for mga8,
> with respect to zombies. All the other packages showing the same problems
> needs to be backported from cauldron to mga8, where this bug was fixed. The
> packages, other than virtualbox, are:
> 
> desktop-common-data
> libcanberra
> mgaonline
> msec
> numlock
> pulseaudio
> qtbase5
> s2u
> systemd
> xdg-compliance
> xdg-user-dirs-gtk
> xinitrc
> 
> I reopen, so to let all the other packages to be backfixed.

I agree totally.
Note that with startplasma-x11 under Cauldron, now there is no any zombie process, even with systemd starting mode for Plasma and with "legacy" starting mode.

See https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ for background for systemd type startup for Plasma 5.21 and onwards.

Status: REOPENED => NEW

then can the fixes be backported into mga8 ?

Of course. I had all the above packages ready for mga8 (except systemd that in the meanwhile was updated for another bug). Will commit them ASAP.

NAK on pushing the systemd bit as part of this update...

There are more systemd fixes coming soon-ish...

Thanks to Giuseppe, this is improved.
Background in Comment 16 and 17.

Suggested Advisory:
========================

Updated xinitrc, xdg-user-dirs-gtk, xdg-compliance, systemd, s2u, qt5base, pulseaudio, numolck, msec, mgaonline, libcanberra, and desktop-common-data fix
spawning zombies processes

The Updated packages fix a bug in the way how shell scripts are parsed/sourced
by some startup binaries (e.g. startplasma-x11).

reference:
https://bugs.mageia.org/show_bug.cgi?id=27362#c17
========================

Preliminary list of updated packages in 8/core/updates_testing:
========================
canberra-common-0.30-15.1.mga8
lib(64)canberra0-0.30-15.1.mga8

desktop-common-data-7.0-2.1.mga8

lib(64)pulseaudio0-14.2-2.1.mga8
lib(64)pulsecommon14.2-14.2-2.1.mga8
lib(64)pulsecore14.2-14.2-2.1.mga8
lib(64)pulseglib20-14.2-2.1.mga8
pulseaudio-14.2-2.1.mga8
pulseaudio-client-config-14.2-2.1.mga8
pulseaudio-module-bluetooth-14.2-2.1.mga8
pulseaudio-module-gsettings-14.2-2.1.mga8
pulseaudio-module-x11-14.2-2.1.mga8
pulseaudio-utils-14.2-2.1.mga8

lib(64)qt5-database-plugin-ibase-5.15.2-4.1.mga8
lib(64)qt5-database-plugin-mysql-5.15.2-4.1.mga8
lib(64)qt5-database-plugin-sqlite-5.15.2-4.1.mga8
lib(64)qt5concurrent5-5.15.2-4.1.mga8
lib(64)qt5core5-5.15.2-4.1.mga8
lib(64)qt5dbus5-5.15.2-4.1.mga8
lib(64)qt5eglfsdeviceintegration5-5.15.2-4.1.mga8
lib(64)qt5eglfskmssupport5-5.15.2-4.1.mga8
lib(64)qt5gui5-5.15.2-4.1.mga8
lib(64)qt5network5-5.15.2-4.1.mga8
lib(64)qt5opengl5-5.15.2-4.1.mga8
lib(64)qt5printsupport5-5.15.2-4.1.mga8
lib(64)qt5sql5-5.15.2-4.1.mga8
lib(64)qt5test5-5.15.2-4.1.mga8
lib(64)qt5widgets5-5.15.2-4.1.mga8
lib(64)qt5xcbqpa5-5.15.2-4.1.mga8
lib(64)qt5xml5-5.15.2-4.1.mga8
qtbase5-common-5.15.2-4.1.mga8

lib(64)systemd0-246.13-1.1.mga8
lib(64)udev-devel-246.13-1.1.mga8
lib(64)udev1-246.13-1.1.mga8
nss-myhostname-246.13-1.1.mga8
systemd-246.13-1.1.mga8

mgaonline-3.31-1.1.mga8
msec-2.9-1.1.mga8
msec-gui-2.9-1.1.mga8

s2u-0.9.2-11.1.mga8

xdg-compliance-1.3.1-2.1.mga8
xdg-compliance-autostart-1.3.1-2.1.mga8
xdg-compliance-menu-1.3.1-2.1.mga8

xdg-user-dirs-gtk-0.10-8.2.mga8

xinitrc-2.4.21-31.1.mga8

from SRPM:
========================
xinitrc-2.4.21-31.1.mga8
xdg-user-dirs-gtk-0.10-8.2.mga8
xdg-compliance-1.3.1-2.1.mga8
systemd-246.13-1.1.mga8
s2u-0.9.2-11.1.mga8
qtbase5-5.15.2-4.1.mga8
pulseaudio-14.2-2.1.mga8
numlock-2.1.2-15.1.mga8
msec-2.9-1.1.mga8
mgaonline-3.31-1.1.mga8
libcanberra-0.30-15.1.mga8
desktop-common-data-7.0-2.1.mga8

Assigning to all packagers for now, as there are pending systemd fixes according to comment 26...

Procedure to test:
1- Under Plasma, look in KSysGuard for zombies process as childs of startplasma-x11;
2- Apply above updates
3- Restart.
4- See no longer zombies process.

Remark:
mgaapplet asks for .rpmsave for /etc/x11/xinitrc.d/msec and with the line
"/usr/bin/xhost + localhost" to be removed. Unsure if I previously added this.

Source RPM: plasma-workspace-5.20.4-4.mga8.src.rpm => xinitrc-2.4.21-31.mga8.src.rpm
Target Milestone: Mageia 8 => ---
Assignee: kde => pkg-bugs
Status comment: (none) => Procedure to test in Comment 26.
Keywords: (none) => has_procedure
Version: Cauldron => 8
Summary: startplasma-x11 spawns zombie process => xinitrc and startplasma-x11 spawn zombie processes

They were uploaded to updates_testing in the meanwhile. Let's wait other Thomas (security?) systemd before final updates.

just drop systemd packages from current update list and assingn the rest for QA...  
I will open up a separate bug for systemd

(In reply to Thomas Backlund from comment #29)
> just drop systemd packages from current update list and assingn the rest for
> QA...  
> I will open up a separate bug for systemd

OK.

Advisory:
========================

Updated xinitrc, xdg-user-dirs-gtk, xdg-compliance, s2u, qt5base, pulseaudio, numolck, msec, mgaonline, libcanberra, and desktop-common-data fix
spawning zombies processes

The Updated packages fix a bug in the way how shell scripts are parsed/sourced
by some startup binaries (e.g. startplasma-x11).

reference:
https://bugs.mageia.org/show_bug.cgi?id=27362#c17
========================

Preliminary list of updated packages in 8/core/updates_testing:
========================
canberra-common-0.30-15.1.mga8
lib(64)canberra0-0.30-15.1.mga8

desktop-common-data-7.0-2.1.mga8

lib(64)pulseaudio0-14.2-2.1.mga8
lib(64)pulsecommon14.2-14.2-2.1.mga8
lib(64)pulsecore14.2-14.2-2.1.mga8
lib(64)pulseglib20-14.2-2.1.mga8
pulseaudio-14.2-2.1.mga8
pulseaudio-client-config-14.2-2.1.mga8
pulseaudio-module-bluetooth-14.2-2.1.mga8
pulseaudio-module-gsettings-14.2-2.1.mga8
pulseaudio-module-x11-14.2-2.1.mga8
pulseaudio-utils-14.2-2.1.mga8

lib(64)qt5-database-plugin-ibase-5.15.2-4.1.mga8
lib(64)qt5-database-plugin-mysql-5.15.2-4.1.mga8
lib(64)qt5-database-plugin-sqlite-5.15.2-4.1.mga8
lib(64)qt5concurrent5-5.15.2-4.1.mga8
lib(64)qt5core5-5.15.2-4.1.mga8
lib(64)qt5dbus5-5.15.2-4.1.mga8
lib(64)qt5eglfsdeviceintegration5-5.15.2-4.1.mga8
lib(64)qt5eglfskmssupport5-5.15.2-4.1.mga8
lib(64)qt5gui5-5.15.2-4.1.mga8
lib(64)qt5network5-5.15.2-4.1.mga8
lib(64)qt5opengl5-5.15.2-4.1.mga8
lib(64)qt5printsupport5-5.15.2-4.1.mga8
lib(64)qt5sql5-5.15.2-4.1.mga8
lib(64)qt5test5-5.15.2-4.1.mga8
lib(64)qt5widgets5-5.15.2-4.1.mga8
lib(64)qt5xcbqpa5-5.15.2-4.1.mga8
lib(64)qt5xml5-5.15.2-4.1.mga8
qtbase5-common-5.15.2-4.1.mga8

mgaonline-3.31-1.1.mga8
msec-2.9-1.1.mga8
msec-gui-2.9-1.1.mga8

s2u-0.9.2-11.1.mga8

xdg-compliance-1.3.1-2.1.mga8
xdg-compliance-autostart-1.3.1-2.1.mga8
xdg-compliance-menu-1.3.1-2.1.mga8

xdg-user-dirs-gtk-0.10-8.2.mga8

xinitrc-2.4.21-31.1.mga8

from SRPM:
========================
xinitrc-2.4.21-31.1.mga8
xdg-user-dirs-gtk-0.10-8.2.mga8
xdg-compliance-1.3.1-2.1.mga8
s2u-0.9.2-11.1.mga8
qtbase5-5.15.2-4.1.mga8
pulseaudio-14.2-2.1.mga8
numlock-2.1.2-15.1.mga8
msec-2.9-1.1.mga8
mgaonline-3.31-1.1.mga8
libcanberra-0.30-15.1.mga8
desktop-common-data-7.0-2.1.mga8

Assignee: pkg-bugs => qa-bugs
Status: NEW => ASSIGNED

(In reply to Aurelien Oudelet from comment #27)

> 
> Remark:
> mgaapplet asks for .rpmsave for /etc/x11/xinitrc.d/msec and with the line
> "/usr/bin/xhost + localhost" to be removed. Unsure if I previously added
> this.

From what I tracked, "/usr/bin/xhost + localhost" was added by /usr/sbin/msec when it's ran at some point, according to your choosen security profile. Re-run /usr/sbin/msec, and it will be readded (if remained in the same profile).

About /etc/x11/xinitrc.d/msec :

Same here, and I know i have not changed anything manually.

(That said, side note, I find the dialogies about file changes very end user unfriendly, but that is another issue discussed long ago...)

----

About list of packages, I think some are missing: the ones below I marked with  a '*' is not in the comment 30 list, but I chose them for installation as version number matches.  I installed on my workstation:

- canberra-common-0.30-15.1.mga8.x86_64
* canberra-gtk-0.30-15.1.mga8.x86_64
- desktop-common-data-7.0-2.1.mga8.noarch
* lib64canberra-gtk0-0.30-15.1.mga8.x86_64
* lib64canberra-gtk3_0-0.30-15.1.mga8.x86_64
* lib64canberra0-0.30-15.1.mga8.x86_64
- lib64pulseaudio0-14.2-2.1.mga8.x86_64
- lib64pulsecommon14.2-14.2-2.1.mga8.x86_64
- lib64pulsecore14.2-14.2-2.1.mga8.x86_64
- lib64pulseglib20-14.2-2.1.mga8.x86_64
- lib64qt5-database-plugin-ibase-5.15.2-4.1.mga8.x86_64
- lib64qt5-database-plugin-mysql-5.15.2-4.1.mga8.x86_64
- lib64qt5-database-plugin-sqlite-5.15.2-4.1.mga8.x86_64
- lib64qt5concurrent5-5.15.2-4.1.mga8.x86_64
- lib64qt5core5-5.15.2-4.1.mga8.x86_64
- lib64qt5dbus5-5.15.2-4.1.mga8.x86_64
- lib64qt5eglfsdeviceintegration5-5.15.2-4.1.mga8.x86_64
- lib64qt5eglfskmssupport5-5.15.2-4.1.mga8.x86_64
- lib64qt5gui5-5.15.2-4.1.mga8.x86_64
- lib64qt5network5-5.15.2-4.1.mga8.x86_64
- lib64qt5opengl5-5.15.2-4.1.mga8.x86_64
- lib64qt5printsupport5-5.15.2-4.1.mga8.x86_64
- lib64qt5sql5-5.15.2-4.1.mga8.x86_64
- lib64qt5test5-5.15.2-4.1.mga8.x86_64
- lib64qt5widgets5-5.15.2-4.1.mga8.x86_64
- lib64qt5xcbqpa5-5.15.2-4.1.mga8.x86_64
- lib64qt5xml5-5.15.2-4.1.mga8.x86_64
- mgaonline-3.31-1.1.mga8.noarch
- msec-2.9-1.1.mga8.x86_64
- msec-gui-2.9-1.1.mga8.x86_64
- pulseaudio-14.2-2.1.mga8.x86_64
- pulseaudio-client-config-14.2-2.1.mga8.x86_64
- pulseaudio-module-bluetooth-14.2-2.1.mga8.x86_64
- pulseaudio-module-gsettings-14.2-2.1.mga8.x86_64
- pulseaudio-module-x11-14.2-2.1.mga8.x86_64
* pulseaudio-module-zeroconf-14.2-2.1.mga8.x86_64
- pulseaudio-utils-14.2-2.1.mga8.x86_64
- qtbase5-common-5.15.2-4.1.mga8.x86_64
- s2u-0.9.2-11.1.mga8.x86_64
- xdg-compliance-1.3.1-2.1.mga8.x86_64
- xdg-compliance-autostart-1.3.1-2.1.mga8.x86_64
- xdg-compliance-menu-1.3.1-2.1.mga8.x86_64
- xdg-user-dirs-gtk-0.10-8.2.mga8.x86_64
- xinitrc-2.4.21-31.1.mga8.noarch

After that it also was hungry for the 32 bitters below so I installed them too:
- libpulseaudio0-14.2-2.1.mga8.i586
- libpulsecommon14.2-14.2-2.1.mga8.i586

(A bit unprofessionaly I use drakrpm with testing enabled and manually select)

(In reply to Morgan Leijström from comment #32)

> After that it also was hungry for the 32 bitters below so I installed them
> too:
> - libpulseaudio0-14.2-2.1.mga8.i586
> - libpulsecommon14.2-14.2-2.1.mga8.i586
> 
> (A bit unprofessionaly I use drakrpm with testing enabled and manually
> select)

Weird with the i586 packages. Were the i586 PA libs packages already installed before? As deps shouldn't be changed.

(In reply to Giuseppe Ghibò from comment #33)
> (In reply to Morgan Leijström from comment #32)
> 
> > After that it also was hungry for the 32 bitters below so I installed them
> > too:
> > - libpulseaudio0-14.2-2.1.mga8.i586
> > - libpulsecommon14.2-14.2-2.1.mga8.i586
> > 
> > (A bit unprofessionaly I use drakrpm with testing enabled and manually
> > select)
> 
> Weird with the i586 packages. Were the i586 PA libs packages already
> installed before? As deps shouldn't be changed.

No. i586 packages were installed if only they are as I use some Wine stuff with Lutris.


Meanwhile, applying updated packages: there is no longer any zombie process.

I have earlier been testing Wine and Lutris, so thats probably the reason yes.

i5 2500, Intel graphics, wired Internet, 64-bit plasma system. Before the update, Ksysguard was showing 5 zombie processes on this system.

Used the list from Comment 30 plus Morgan's additions from Comment 32 in qarepo. It found all the packages in testing, so yes, Morgan's additions are valid.

The following 41 packages are going to be installed:

- canberra-common-0.30-15.1.mga8.x86_64
- canberra-gtk-0.30-15.1.mga8.x86_64
- desktop-common-data-7.0-2.1.mga8.noarch
- lib64canberra-gtk3_0-0.30-15.1.mga8.x86_64
- lib64canberra0-0.30-15.1.mga8.x86_64
- lib64pulseaudio0-14.2-2.1.mga8.x86_64
- lib64pulsecommon14.2-14.2-2.1.mga8.x86_64
- lib64pulsecore14.2-14.2-2.1.mga8.x86_64
- lib64pulseglib20-14.2-2.1.mga8.x86_64
- lib64qt5-database-plugin-ibase-5.15.2-4.1.mga8.x86_64
- lib64qt5-database-plugin-mysql-5.15.2-4.1.mga8.x86_64
- lib64qt5-database-plugin-sqlite-5.15.2-4.1.mga8.x86_64
- lib64qt5concurrent5-5.15.2-4.1.mga8.x86_64
- lib64qt5core5-5.15.2-4.1.mga8.x86_64
- lib64qt5dbus5-5.15.2-4.1.mga8.x86_64
- lib64qt5eglfsdeviceintegration5-5.15.2-4.1.mga8.x86_64
- lib64qt5eglfskmssupport5-5.15.2-4.1.mga8.x86_64
- lib64qt5gui5-5.15.2-4.1.mga8.x86_64
- lib64qt5network5-5.15.2-4.1.mga8.x86_64
- lib64qt5opengl5-5.15.2-4.1.mga8.x86_64
- lib64qt5printsupport5-5.15.2-4.1.mga8.x86_64
- lib64qt5sql5-5.15.2-4.1.mga8.x86_64
- lib64qt5test5-5.15.2-4.1.mga8.x86_64
- lib64qt5widgets5-5.15.2-4.1.mga8.x86_64
- lib64qt5xcbqpa5-5.15.2-4.1.mga8.x86_64
- lib64qt5xml5-5.15.2-4.1.mga8.x86_64
- mgaonline-3.31-1.1.mga8.noarch
- msec-2.9-1.1.mga8.x86_64
- msec-gui-2.9-1.1.mga8.x86_64
- pulseaudio-14.2-2.1.mga8.x86_64
- pulseaudio-client-config-14.2-2.1.mga8.x86_64
- pulseaudio-module-gsettings-14.2-2.1.mga8.x86_64
- pulseaudio-module-x11-14.2-2.1.mga8.x86_64
- pulseaudio-utils-14.2-2.1.mga8.x86_64
- qtbase5-common-5.15.2-4.1.mga8.x86_64
- s2u-0.9.2-11.1.mga8.x86_64
- xdg-compliance-1.3.1-2.1.mga8.x86_64
- xdg-compliance-autostart-1.3.1-2.1.mga8.x86_64
- xdg-compliance-menu-1.3.1-2.1.mga8.x86_64
- xdg-user-dirs-gtk-0.10-8.2.mga8.x86_64
- xinitrc-2.4.21-31.1.mga8.noarch

No installation issues. After a reboot, Ksysguard is still showing one zombie, but it is related to systemd, which is to be addressed in another bug. (Comment 29)

So, looks OK here.

Dell Dimension e520, Core2Quad, AMD HD 8570 graphics, rtl8192cu wifi, 32-bit Plasma system.

Essentially the same situation as in Comment 36, except that it is a 32-bit system. Before the update, Ksysguard was showing the same 5 zombie processes, and after updating the 32-bit versions of the same packages, only one zombie remained, the one connected to systemd.

Looks OK for 32-bits. Giving this an OK for both arches. Not validating yet, as I did not follow the procedure outlined in Comment 16, but merely used a Plasma GUI to look for zombies, as was done early in this bug. If that is sufficient, I have no objection to validating.

Whiteboard: (none) => MGA8-64-OK MGA8-32-OK

(In reply to Thomas Andrews from comment #36)

> 
> No installation issues. After a reboot, Ksysguard is still showing one
> zombie, but it is related to systemd, which is to be addressed in another
> bug. (Comment 29)
> 
> So, looks OK here.

Did you skipped systemd-246.13-1.1.mga8, or you were getting another zombies with it? As from what I understand the next systemd bugs, are not related to further zombies.

(In reply to Giuseppe Ghibò from comment #38)
> (In reply to Thomas Andrews from comment #36)
> 
> > 
> > No installation issues. After a reboot, Ksysguard is still showing one
> > zombie, but it is related to systemd, which is to be addressed in another
> > bug. (Comment 29)
> > 
> > So, looks OK here.
> 
> Did you skipped systemd-246.13-1.1.mga8, or you were getting another zombies
> with it? As from what I understand the next systemd bugs, are not related to
> further zombies.

No, I think Thomas did not install systemd-246.13-1.1.mga8.
I have installed it and there is not any Zombie now.

(In reply to Thomas Andrews from comment #37)

> Looks OK for 32-bits. Giving this an OK for both arches. Not validating yet,
> as I did not follow the procedure outlined in Comment 16, but merely used a
> Plasma GUI to look for zombies, as was done early in this bug. If that is
> sufficient, I have no objection to validating.

Actually, even with no zombies, as I stated above, the plasma session still have minutes timeout after X11 zapping (just pressing ctrl-alt-backspace) with kwin_x11 process eating all the cpu cycles and splash screen stuck with the progress bar. At this point that's another bug that we should open or that is already opened (e.g. #27147 or #27180). AFAIK it doesn't happens on plasma with wayland (it doesn't use kwin_x11 but kwin_wayland and the login procedure there is different).

I don't know if this is related (because it's on wayland), but there is an interesting comment here, https://bugzilla.redhat.com/show_bug.cgi?id=1897717#c29 saying it was related to changes in dbus activation here: https://invent.kde.org/plasma/plasma-workspace/-/commit/1e444c864fc175b3826c88a51a5e2c9f95e497c3. We might try a local build reverting the change and see what happens.

(In reply to Giuseppe Ghibò from comment #40)
> (In reply to Thomas Andrews from comment #37)
> 
> > Looks OK for 32-bits. Giving this an OK for both arches. Not validating yet,
> > as I did not follow the procedure outlined in Comment 16, but merely used a
> > Plasma GUI to look for zombies, as was done early in this bug. If that is
> > sufficient, I have no objection to validating.
> 
> Actually, even with no zombies, as I stated above, the plasma session still
> have minutes timeout after X11 zapping (just pressing ctrl-alt-backspace)
> with kwin_x11 process eating all the cpu cycles and splash screen stuck with
> the progress bar. At this point that's another bug that we should open or
> that is already opened (e.g. #27147 or #27180). AFAIK it doesn't happens on
> plasma with wayland (it doesn't use kwin_x11 but kwin_wayland and the login
> procedure there is different).
> 
> I don't know if this is related (because it's on wayland), but there is an
> interesting comment here,
> https://bugzilla.redhat.com/show_bug.cgi?id=1897717#c29 saying it was
> related to changes in dbus activation here:
> https://invent.kde.org/plasma/plasma-workspace/-/commit/
> 1e444c864fc175b3826c88a51a5e2c9f95e497c3. We might try a local build
> reverting the change and see what happens.

On a cold boot, landing to sddm, you can open perfectly a X11 Plasma session.
But as soon as you logoff this session, THAT session "c2" according to loginctl facility is *still* open with remaining processes. This is recorded as MGA bug 27147 for Mageia 8.

For Mageia 7 with Bug 27180, I do think it is same.

There is something strange in the way we are configured to not remove all session stuff after a logoff. I do think systemd --user should remove all processes that are launched after a logon.

I do think this can be solved with Plasma 5.21 and onward with systemd starting facility.

But, that is strange meanwhile:
if you look at /var/log/Xorg.0.log:
 - when you log a graphical session from sddm, there is a complain about missing -keeptty and logind facility desactivated.
 - when you log in a tty and then do startx to start a graphical session, this line is changed with logind activated.

and logind is responsible to track session.
And then, logoff a graphical session started from startx completely remove all graphical processes. Later logoff from the tty remove all remaining process belonging to the user (on Mageia 8).

Digging more later.

We should track the issue in Bug 27147 after pushing this today.

(In reply to Aurelien Oudelet from comment #41)

> (In reply to Giuseppe Ghibò from comment #40)
> > (In reply to Thomas Andrews from comment #37)
> > 
> > > Looks OK for 32-bits. Giving this an OK for both arches. Not validating yet,
> > > as I did not follow the procedure outlined in Comment 16, but merely used a
> > > Plasma GUI to look for zombies, as was done early in this bug. If that is
> > > sufficient, I have no objection to validating.
> > 
> > Actually, even with no zombies, as I stated above, the plasma session still
> > have minutes timeout after X11 zapping (just pressing ctrl-alt-backspace)
> > with kwin_x11 process eating all the cpu cycles and splash screen stuck with
> > the progress bar. At this point that's another bug that we should open or
> > that is already opened (e.g. #27147 or #27180). AFAIK it doesn't happens on
> > plasma with wayland (it doesn't use kwin_x11 but kwin_wayland and the login
> > procedure there is different).
> > 
> > I don't know if this is related (because it's on wayland), but there is an
> > interesting comment here,
> > https://bugzilla.redhat.com/show_bug.cgi?id=1897717#c29 saying it was
> > related to changes in dbus activation here:
> > https://invent.kde.org/plasma/plasma-workspace/-/commit/
> > 1e444c864fc175b3826c88a51a5e2c9f95e497c3. We might try a local build
> > reverting the change and see what happens.
> 
> On a cold boot, landing to sddm, you can open perfectly a X11 Plasma session.
> But as soon as you logoff this session, THAT session "c2" according to
> loginctl facility is *still* open with remaining processes. This is recorded
> as MGA bug 27147 for Mageia 8.
> 
> For Mageia 7 with Bug 27180, I do think it is same.

With plasma5 of mga7 I couldn't reproduce the problem. I tried X11-zapping dozens of times in a row, but the login is always successful and with no delays there.

> 
> There is something strange in the way we are configured to not remove all
> session stuff after a logoff. I do think systemd --user should remove all
> processes that are launched after a logon.

Actually the startplasma-x11 is not performed by systemd, but by Xsession. what startplasma-x11 does is also to be "insentive" to SIGHUP, and has its own shutdown procedure.

> 
> I do think this can be solved with Plasma 5.21 and onward with systemd
> starting facility.
> 
> But, that is strange meanwhile:
> if you look at /var/log/Xorg.0.log:
>  - when you log a graphical session from sddm, there is a complain about
> missing -keeptty and logind facility desactivated.
>  - when you log in a tty and then do startx to start a graphical session,
> this line is changed with logind activated.

Note that it's also not related to the desktop manager (sddm or anything other). The procedure in comment #16 is to start X11 without the session manager.

> 
> and logind is responsible to track session.
> And then, logoff a graphical session started from startx completely remove
> all graphical processes. Later logoff from the tty remove all remaining
> process belonging to the user (on Mageia 8).
> 
> Digging more later.

From what I quickly glanced at other distro where this doesn't happen anymore, they are adding a certain amount of login services (provided by plasma workspace code) in /usr/lib/systemd/user/plasma5*.service, e.g.:

/usr/lib/systemd/user/plasma-core.target
/usr/lib/systemd/user/plasma-gmenudbusmenuproxy.service
/usr/lib/systemd/user/plasma-kcminit-phase1.service
/usr/lib/systemd/user/plasma-kcminit.service
/usr/lib/systemd/user/plasma-krunner.service
/usr/lib/systemd/user/plasma-ksmserver.service
/usr/lib/systemd/user/plasma-ksplash-ready.service
/usr/lib/systemd/user/plasma-plasmashell.service
/usr/lib/systemd/user/plasma-restoresession.service
/usr/lib/systemd/user/plasma-workspace@.target
/usr/lib/systemd/user/plasma-xembedsniproxy.service

From what I see, from plasma-workspace 5.15 to 5.19 where the problems begun, the startkde bash script was replaced with a C++ code startplasma-x11 which resemble the same bash commands. If I understand correctly, both ways of starting up Plasma are supported upstream and equally valid, though actually the one within systemd seems much more robust. Let's move plasma discussion to #27147.

(In reply to Giuseppe Ghibò from comment #38)
> (In reply to Thomas Andrews from comment #36)
> 
> > 
> > No installation issues. After a reboot, Ksysguard is still showing one
> > zombie, but it is related to systemd, which is to be addressed in another
> > bug. (Comment 29)
> > 
> > So, looks OK here.
> 
> Did you skipped systemd-246.13-1.1.mga8, or you were getting another zombies
> with it? As from what I understand the next systemd bugs, are not related to
> further zombies.

I skipped it because of what TMB said in Comment 29: "just drop systemd packages from current update list and assingn the rest for QA...  
I will open up a separate bug for systemd"

So I believed at the time that meant we were to test the packages without systemd. If a systemd test is needed, but that is to be addressed in another bug, and not to go out with these packages, then that systemd bug should be made a block of this one.

Or do I have that policy all wrong?

According to (In reply to Thomas Andrews from comment #44)
> (In reply to Giuseppe Ghibò from comment #38)
> > (In reply to Thomas Andrews from comment #36)
> > 
> > > 
> > > No installation issues. After a reboot, Ksysguard is still showing one
> > > zombie, but it is related to systemd, which is to be addressed in another
> > > bug. (Comment 29)
> > > 
> > > So, looks OK here.
> > 
> > Did you skipped systemd-246.13-1.1.mga8, or you were getting another zombies
> > with it? As from what I understand the next systemd bugs, are not related to
> > further zombies.
> 
> I skipped it because of what TMB said in Comment 29: "just drop systemd
> packages from current update list and assingn the rest for QA...  
> I will open up a separate bug for systemd"

I understand that there were further fixes for systemd coming to cumulate, related to other bugs, so it was to skip in the official core/updates, so to have all merged in a single shot for the official core/updates

After a normal cold boot using sddm on the updated 64-bit system, the one zombie I still see in Ksysguard is labeled 50-systemd-user and is a sub-process of startplasma-x11, which itself is a sub-process of sddm-helper, which is a sub-process of sddm.

On the 32-bit system, a cold boot using run level 3 and startx, bypassing sddm, Ksysguard doesn't show any zombies at all.

Validating.
Advisory pushed without systemd SRPM.

CC: (none) => sysadmin-bugs
Keywords: (none) => advisory, validated_update

(In reply to Thomas Andrews from comment #46)
> After a normal cold boot using sddm on the updated 64-bit system, the one
> zombie I still see in Ksysguard is labeled 50-systemd-user and is a
> sub-process of startplasma-x11, which itself is a sub-process of
> sddm-helper, which is a sub-process of sddm.
> 
> On the 32-bit system, a cold boot using run level 3 and startx, bypassing
> sddm, Ksysguard doesn't show any zombies at all.

After the systemd update does get pushed, please open a new bug report for
this specific zombie, if it's still present.

Unvalidating.

qtbase5 is being rebuild in BS

Blocks: (none) => 28824
Keywords: advisory, validated_update => (none)

or just handle the qtbase5 update bits in bug 28824

(In reply to Thomas Backlund from comment #50)
> or just handle the qtbase5 update bits in bug 28824

True.

qtbase5 changes are tracked in Bug 28824.
systemd changes are tracked in Bug 28859.

Revalidating.

Latest Advisory:
========================

Updated xinitrc, xdg-user-dirs-gtk, xdg-compliance, s2u, pulseaudio, numolck, msec, mgaonline, libcanberra, and desktop-common-data fix
spawning zombies processes

The Updated packages fix a bug in the way how shell scripts are parsed/sourced
by some startup binaries (e.g. startplasma-x11).

reference:
https://bugs.mageia.org/show_bug.cgi?id=27362#c17
========================

Preliminary list of updated packages in 8/core/updates_testing:
========================
canberra-common-0.30-15.1.mga8
lib(64)canberra0-0.30-15.1.mga8
lib(64)canberra-gtk0-0.30-15.1.mga8
lib(64)canberra-gtk3_0-0.30-15.1.mga8
canberra-gtk-0.30-15.1.mga8

desktop-common-data-7.0-2.1.mga8

lib(64)pulseaudio0-14.2-2.1.mga8
lib(64)pulsecommon14.2-14.2-2.1.mga8
lib(64)pulsecore14.2-14.2-2.1.mga8
lib(64)pulseglib20-14.2-2.1.mga8
pulseaudio-14.2-2.1.mga8
pulseaudio-client-config-14.2-2.1.mga8
pulseaudio-module-bluetooth-14.2-2.1.mga8
pulseaudio-module-gsettings-14.2-2.1.mga8
pulseaudio-module-x11-14.2-2.1.mga8
pulseaudio-module-zeroconf-14.2-2.1.mga8
pulseaudio-utils-14.2-2.1.mga8


mgaonline-3.31-1.1.mga8
msec-2.9-1.1.mga8
msec-gui-2.9-1.1.mga8

s2u-0.9.2-11.1.mga8

xdg-compliance-1.3.1-2.1.mga8
xdg-compliance-autostart-1.3.1-2.1.mga8
xdg-compliance-menu-1.3.1-2.1.mga8

xdg-user-dirs-gtk-0.10-8.2.mga8

xinitrc-2.4.21-31.1.mga8

from SRPM:
========================
xinitrc-2.4.21-31.1.mga8
xdg-user-dirs-gtk-0.10-8.2.mga8
xdg-compliance-1.3.1-2.1.mga8
s2u-0.9.2-11.1.mga8
pulseaudio-14.2-2.1.mga8
numlock-2.1.2-15.1.mga8
msec-2.9-1.1.mga8
mgaonline-3.31-1.1.mga8
libcanberra-0.30-15.1.mga8
desktop-common-data-7.0-2.1.mga8

Keywords: (none) => advisory, validated_update

Fully updated packages list in core/updates_testing:
========================
canberra-common-0.30-15.1.mga8
canberra-gtk-0.30-15.1.mga8
lib(64)canberra-devel-0.30-15.1.mga8
lib(64)canberra-gtk-devel-0.30-15.1.mga8
lib(64)canberra-gtk0-0.30-15.1.mga8
lib(64)canberra-gtk3_0-0.30-15.1.mga8
lib(64)canberra-gtk3-devel-0.30-15.1.mga8
lib(64)canberra0-0.30-15.1.mga8

desktop-common-data-7.0-2.1.mga8

mgaonline-3.31-1.1.mga8

msec-2.9-1.1.mga8
msec-gui-2.9-1.1.mga8

numlock-2.1.2-15.1.mga8

pulseaudio-14.2-2.1.mga8
pulseaudio-client-config-14.2-2.1.mga8
pulseaudio-esound-compat-14.2-2.1.mga8
pulseaudio-module-bluetooth-14.2-2.1.mga8
pulseaudio-module-equalizer-14.2-2.1.mga8
pulseaudio-module-gsettings-14.2-2.1.mga8
pulseaudio-module-jack-14.2-2.1.mga8
pulseaudio-module-lirc-14.2-2.1.mga8
pulseaudio-module-x11-14.2-2.1.mga8
pulseaudio-module-zeroconf-14.2-2.1.mga8
pulseaudio-utils-14.2-2.1.mga8
lib(64)pulseaudio-devel-14.2-2.1.mga8
lib(64)pulseaudio0-14.2-2.1.mga8
lib(64)pulsecommon14.2-14.2-2.1.mga8
lib(64)pulsecore14.2-14.2-2.1.mga8
lib(64)pulseglib20-14.2-2.1.mga8

s2u-0.9.2-11.1.mga8

xdg-compliance-1.3.1-2.1.mga8
xdg-compliance-autostart-1.3.1-2.1.mga8
xdg-compliance-menu-1.3.1-2.1.mga8

xdg-user-dirs-gtk-0.10-8.2.mga8

xinitrc-2.4.21-31.1.mga8

=======================
from SRPMs:

desktop-common-data-7.0-2.1.mga8
libcanberra-0.30-15.1.mga8
mgaonline-3.31-1.1.mga8
msec-2.9-1.1.mga8
numlock-2.1.2-15.1.mga8
pulseaudio-14.2-2.1.mga8
s2u-0.9.2-11.1.mga8
xdg-compliance-1.3.1-2.1.mga8
xdg-user-dirs-gtk-0.10-8.2.mga8
xinitrc-2.4.21-31.1.mga8

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0100.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED

Updated Errata

Note that this package is also affected:

motif-2.3.8-2.mga8

because of:
/etc/X11/xinit/xinitrc.d/xmbind.sh

(In reply to Aurelien Oudelet from comment #55)
> Note that this package is also affected:
> 
> motif-2.3.8-2.mga8
> 
> because of:
> /etc/X11/xinit/xinitrc.d/xmbind.sh

So open separate bug?

(In reply to Morgan Leijström from comment #56)
> (In reply to Aurelien Oudelet from comment #55)
> > Note that this package is also affected:
> > 
> > motif-2.3.8-2.mga8
> > 
> > because of:
> > /etc/X11/xinit/xinitrc.d/xmbind.sh
> 
> So open separate bug?

Yes. The update that this bug was about was pushed to the updates repo
already. The new bug should reference this bug.