Shell script fails to kill-off child processes upon app closure and sandbox termination #5897
Comments
|
These are possibly relevant: #3224 (comment) Maybe I could try something like this #3224 (comment), but to me it looks it may be better to find a native solution. |
|
Enable |
|
However, killing zombie processes does not help because killing them is a no-op. Maybe runit can not collect zombie processes inside pid-namespaces or has some other bug with it? |
|
I just modified the script with And no, those zombie processes still linger. Indeed, it may be a |
|
Okay, I had a chat with Void Linux devs on IRC: They say those blocks of Are not technically zombie processes. Indeed, since those were spawned with |
rusty-snake
added
the
notourbug
TeusLollo
changed the title
|
OK, just to clarify, since the documentation isn't entirely helpful on this: Here Is this supported, or should I just close-down the issue? |
|
OK, some more chats have confirmed that this probably is not a Closing this. |
kmk3
changed the title
kmk3
changed the title
Yes, systemd apparently does some dbus-related things by itself as it depends
The user dbus process is indeed intended to stay around, but it's usually only What happens if dbus-launch is executed in the sway config and then (after a See for example: And the following file, which is provided by #!/bin/sh
# launches a session dbus instance
dbuslaunch="$(command -v dbus-launch)"
if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ] && [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
if [ -n "$command" ]; then
command="$dbuslaunch --exit-with-session $command"
else
eval " $($dbuslaunch --sh-syntax --exit-with-session)"
fi
fiMaybe Void has something similar. |
Upon more testing, I have confirmed that, in fact I have no need (Anymore, at least) to use In every case, it is better to dismiss such an heavy usage of Indeed, I have discovered that In every case, Void devs have promised to eventually clarify this matter, and their preferred method of setting-up window managers, on their own handbook, thus the matter should eventually be cleared. Thanks for your help. |
Description
It seems that, at least on non-
systemddistros (Utilizingrunitas init, in my case) varying zombie processes are leftover upon sandbox termination given interaction withdbus-launch gsettingscommand (Which, on non-systemddistros, is largely necessary to properly set-up custom GTK themes, icons, cursors, and similar) in a custom script.May be at least partially related to #3949 and #3224
Steps to Reproduce
It is given the following:
A non-
systemddistro (Void Linux, in my case, which runs onrunitas init system)swayas window manager.No login manager (
swayis run on a custom config through a custom script)A
LibreWolfAppImage (From https://gitlab.com/librewolf-community/browser/appimage/-/packages)A custom
.local/share/applications/LibreWolf_Firejailed/freedesktop-based app setup, which operates as follows:LibreWolf_Firejailed.desktopHence,
LibreWolf_Firejailed.desktoploadslibrewolf_firejailed.sh, the latter being thus compiled:Thus,
librewolf_firejailed.shexecutesdbus-launch gsettingsto import relevant custom theming, and relies upon a customlibrewolf_firejailed.profile, the latter being here described:Expected behavior
This fairly involved custom setup was necessary on my side to properly sandbox an AppImage-based browser, and correctly import
$gnome_schemavariables. Indeed, the AppImage-based browser runs perfectly, and correctly imports system themes with this setup (While, without utilizing thedbus-launch gsettings-based schemes, it would absolutely not import custom theming), while otherwise appearing to be properly firejailed. However...Actual behavior
...It appears that, although the AppImage-based browser runs fine, and is properly terminated by the
swayWM (Default keys Super + Shift + Q, depending onswayconfig, thus I remark that the AppImage-based browser is closed-down by the WM), child processes presumably spawned by thedbus-launch gsettingscommands to remain lingering after the sandbox has been closed.In fact:
syslogreports the following:It never however reports on those
dbus-daemonbeing terminated. Also:pstree:Those
dbus-daemonare not visible onpstree. And also:firejail --list:4486:username::firejail --appimage --apparmor --profile=/home/username/.local/share/applications/LibreWolf_Firejailed/librewolf_firejailed.profile /home/username/.bin/LibreWolf.x86_64.AppImageIndeed,
firejail --listdoes not list suchdbus-daemon.ps auxf, however:Those blocks of
remain lingering after EACH sandbox is terminated. Thus, each time the AppImage-browser is closed, a new block of those
is spawned, and remains lingering until system shut-off, or manual termination.
It is even easier to locate such blocks with
htop, but unfortunately pastinghtopoutput is fairly difficult.Behavior without a profile
Not applicable here.
Additional context
Not sure. The above wall of text should be fairly self-evident. This is an edge case, after all, and largely depends upon usage of
dbus-launch gsettings, which is however necessary on nonsystemddistros to ensure that GTK custom theming "sticks".It should also be noted that
swayDM also launches its own scheme ofYet that is not sufficient to force sandboxed applications to import
$gnome_schemavariables.Environment
Void Linux with
runitas init.firejail version 0.9.72
Compile time support:
- always force nonewprivs support is disabled
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- D-BUS proxy support is enabled
- file transfer support is enabled
- firetunnel support is disabled
- IDS support is disabled
- networking support is enabled
- output logging is enabled
- overlayfs support is disabled
- private-home support is enabled
- private-cache and tmpfs as user enabled
- SELinux support is disabled
- user namespace support is enabled
- X11 sandboxing support is enabled
Checklist
firejail, since there would never be any use of thedbus-launch gsettingsworkaround).--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages). Indeed I have, and you can read for yourself the contents of such a custom profile above.Log
Logs are provided above, this is an edge case. I can perform more tests if necessary.
The text was updated successfully, but these errors were encountered: