Bug 473702 - plasmashell does not disown child processes, making restarting plasmashell kill applications too
Summary: plasmashell does not disown child processes, making restarting plasmashell ki...
Status: REPORTED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 482734 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-08-23 22:32 UTC by Martin
Modified: 2024-03-07 23:35 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin 2023-08-23 22:32:02 UTC
SUMMARY
Some processes that are launched are set as children of plasmashell and do not get disowned.

This is very problematic when ending the plasmashell process with CTRL+C, as it sends SIGINT to its children processes, which happens to kill chromium and some other apps on my system.

I do this often at the moment, as I am experiencing freezes and have to restart plasmashell, which is a story for another bug report.


STEPS TO REPRODUCE
1. Relaunch plasmashell in a terminal with `plasmashell --replace`
2. Launch Chromium
3. Check htop or similar tool to see that chromium is a child process of plasmashell
4. Press CTRL+C in the plasmashell terminal window

OBSERVED RESULT
Both plasmashell and chromium have gone the way of the saber-toothed tiger

EXPECTED RESULT
Only plasmashell says goodbye

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.109.0
Qt Version: 5.15.10
Kernel Version: 6.4.10-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 62.0 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4090/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X670 AORUS ELITE AX
System Version: -CF

ADDITIONAL INFORMATION

Chromium launched from an icon on the plasmashell start menu(not sure of the proper name).

This has been an issue for a while as I first started poking into this in 2021-05 but never got around to reporting it, older conversations can be found on the unofficial Telegram group starting here - https://t.me/kdecommunity/74113
Comment 1 Martin 2023-08-24 06:44:40 UTC
Actually no need for CTRL+C, running plasmashell --replace again does the job too.
Comment 2 Nate Graham 2023-08-28 20:05:37 UTC
Are you using a system with the systemd boot process disabled?
Comment 3 Martin 2023-08-28 22:11:20 UTC
Do you mean using the systemd startup thing - https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ ?

This shows up as disabled on my system:

systemctl --user status plasma-plasmashell.service
Comment 4 Nate Graham 2023-08-28 22:14:22 UTC
I had a feeling. This was one of the issues that the systemd-based startup process was specifically developed to solve. :) I would recommend re-enabling it.
Comment 5 Martin 2023-08-28 22:15:25 UTC
I never manually disabled it, but this is a system from... 2021-06-27, and I presume it wasn't a forced switch for older systems?
Comment 6 Martin 2023-08-28 22:19:39 UTC
Actually no, despite not being enabled, it does run on startup, I just got confused because it was killed 4 days ago, but my uptime is indeed 4 days.

% uptime -p              
up 4 days, 6 hours, 6 minutes

% systemctl --user status plasma-plasmashell.service                    

○ plasma-plasmashell.service - KDE Plasma Workspace
     Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; preset: enabled)
     Active: inactive (dead) since Thu 2023-08-24 23:49:35 CEST; 4 days ago
   Duration: 5h 36min 54.633s
    Process: 6451 ExecStart=/usr/bin/plasmashell --no-respawn (code=exited, status=0/SUCCESS)
   Main PID: 6451 (code=exited, status=0/SUCCESS)
        CPU: 11min 25.152s

...
Aug 24 23:49:35 Luxuria plasmashell[6451]:   zwp_linux_dmabuf_v1@29 still attached
Aug 24 23:49:35 Luxuria systemd[5311]: plasma-plasmashell.service: Consumed 11min 25.152s CPU time.
Comment 7 Nate Graham 2023-08-29 15:40:42 UTC
Ok, so you are using the systemd-enabled boot.

But it sounds like you're also manually running the plasmashell process such that you can Ctrl+C it? Can you maybe expand on your use cases and what/how/why you're manually running and restarting plasmashell?
Comment 8 Martin 2023-08-30 09:48:57 UTC
I have panel freezes (most likely due to a specific widget, still testing that) that require me to restart plasmashell.
Comment 9 Nate Graham 2023-08-30 16:25:29 UTC
Got it. So if you restart plasmashell using `systemctl restart --user plasma-plasmashell.service` instead of `plasmashell --replace`, does the problem still happen?
Comment 10 Martin 2023-08-30 17:11:13 UTC
Yep, still crashes chromium, it's still parented under plasmashell before and after the restart(on relaunch) with systemctl.
Comment 11 Nate Graham 2023-08-30 17:31:00 UTC
Hmm, that's not what I was expecting. Are you 100% sure that plasmashell was running under systemd though? In other words, can you do this:

killall -9 plasmashell
systemctl restart --user plasma-plasmashell.service
[start Chromium]
systemctl restart --user plasma-plasmashell.service

And then does Chromium still get killed?

If it does, can you expand on how you're launching Chromium? And also mention whether it only affects Chromium, or all apps launched using the same method?
Comment 12 Martin 2023-08-30 17:51:47 UTC
> does Chromium still get killed?

Yes, it's not a 100% chance though, but it does happen most of the time.

> mention whether it only affects Chromium, or all apps launched using the same method?

Seems like all apps, got the same on Tauon Music Box, which is a Python music player

> can you expand on how you're launching Chromium? 

That seems to be very relevant, I am launching it through a pinned icon on the panel. 

If I launch it through a terminal, it is not parented to plasmashell and thus does not suffer from the same issue.
Comment 13 Nate Graham 2023-08-31 16:55:20 UTC
Thanks. Unfortunately I am rather confused and not sure how to proceed from here. :/
Comment 14 Nate Graham 2024-03-07 23:35:55 UTC
*** Bug 482734 has been marked as a duplicate of this bug. ***