[GH-ISSUE #3224] Firejail not tearing down sandbox after closing VLC

gitea-mirror commented

2026-05-05 08:41:32 -06:00

Owner

Originally created by @Futureknows on GitHub (Feb 14, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3224

I've noticed a few apps do this when jailed. The app appears to close, but upon inspection the sandbox is still running. With VLC it prevents a new instance from launching until I manually kill the sandbox or the orphaned process.

Has anyone else noticed this behaviour?

Originally created by @Futureknows on GitHub (Feb 14, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3224 I've noticed a few apps do this when jailed. The app appears to close, but upon inspection the sandbox is still running. With VLC it prevents a new instance from launching until I manually kill the sandbox or the orphaned process. Has anyone else noticed this behaviour?

gitea-mirror commented

2026-05-05 08:41:34 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 14, 2020):

I have seen this with zombie processes. Firejail keeps jails open if the app that was originally jailed created zombies when it was shut down. These are easy to spot with firetools fstat tool - they show up as jailed processes that use no memory.

@jonleivent commented on GitHub (Feb 14, 2020): I have seen this with zombie processes. Firejail keeps jails open if the app that was originally jailed created zombies when it was shut down. These are easy to spot with firetools fstat tool - they show up as jailed processes that use no memory.

gitea-mirror commented

2026-05-05 08:41:34 -06:00

Author

Owner

@Futureknows commented on GitHub (Feb 14, 2020):

Thanks. I wonder what might help prevent it, maybe loosening the sandbox? I'll look for common parameters in the offending firejails.

@Futureknows commented on GitHub (Feb 14, 2020): Thanks. I wonder what might help prevent it, maybe loosening the sandbox? I'll look for common parameters in the offending firejails.

gitea-mirror commented

2026-05-05 08:41:35 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 14, 2020):

I strongly doubt that changing the sandbox parameters will have any effect. If it is a zombie process, then the fault lies with the app itself, not with firejail. There might be a way to enhance firejail itself so that when it notices it has zombie children, it removes them - but that is not a behavior that can be achieved by altering sandbox parameters.

@jonleivent commented on GitHub (Feb 14, 2020): I strongly doubt that changing the sandbox parameters will have any effect. If it is a zombie process, then the fault lies with the app itself, not with firejail. There might be a way to enhance firejail itself so that when it notices it has zombie children, it removes them - but that is not a behavior that can be achieved by altering sandbox parameters.

gitea-mirror commented

2026-05-05 08:41:36 -06:00

Author

Owner

@Futureknows commented on GitHub (Feb 14, 2020):

The orphaned processes only persist when sandboxed. If I run VLC outside
firejail the process closes normally. It seems like it has to be an
interaction with the sandbox

On Fri, Feb 14, 2020 at 10:21 AM Jonathan Leivent notifications@github.com
wrote:

I strongly doubt that changing the sandbox parameters will have any
effect. If it is a zombie process, then the fault lies with the app itself,
not with firejail. There might be a way to enhance firejail itself so that
when it notices it has zombie children, it removes them - but that is not a
behavior that can be achieved by altering sandbox parameters.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/netblue30/firejail/issues/3224?email_source=notifications&email_token=AFAS62YVSHPS3MPKW5SLVVDRC3VMJA5CNFSM4KVBTL72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL2EXUQ#issuecomment-586435538,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAS62YBCCS2G7RKI5I35STRC3VMJANCNFSM4KVBTL7Q
.

@Futureknows commented on GitHub (Feb 14, 2020): The orphaned processes only persist when sandboxed. If I run VLC outside firejail the process closes normally. It seems like it has to be an interaction with the sandbox On Fri, Feb 14, 2020 at 10:21 AM Jonathan Leivent <notifications@github.com> wrote: > I strongly doubt that changing the sandbox parameters will have any > effect. If it is a zombie process, then the fault lies with the app itself, > not with firejail. There might be a way to enhance firejail itself so that > when it notices it has zombie children, it removes them - but that is not a > behavior that can be achieved by altering sandbox parameters. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/netblue30/firejail/issues/3224?email_source=notifications&email_token=AFAS62YVSHPS3MPKW5SLVVDRC3VMJA5CNFSM4KVBTL72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL2EXUQ#issuecomment-586435538>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFAS62YBCCS2G7RKI5I35STRC3VMJANCNFSM4KVBTL7Q> > . >

gitea-mirror commented

2026-05-05 08:41:37 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 14, 2020):

That is probably because the linux init process already has the ability to deal with zombies that it directly inherits, which is what normally happens when zombies are created . But, if the zombie process is created in a firejail sandbox, then it never gets directly inherited by the linux init process. Not allowing processes to escape a sandbox is normally considered a major firejail feature, but in the case of zombies it is admittedly a nuisance.

I do think it is possible for firejail to handle zombies itself, but it would not be something achievable merely by altering the existing sandboxing parameters. It might require firejail to have some kind of daemon running that watches for the presence of zombie processes in sandboxes. But I'll leave that determination to the firejail developers.

@jonleivent commented on GitHub (Feb 14, 2020): That is probably because the linux init process already has the ability to deal with zombies that it directly inherits, which is what normally happens when zombies are created . But, if the zombie process is created in a firejail sandbox, then it never gets directly inherited by the linux init process. Not allowing processes to escape a sandbox is normally considered a major firejail feature, but in the case of zombies it is admittedly a nuisance. I do think it is possible for firejail to handle zombies itself, but it would not be something achievable merely by altering the existing sandboxing parameters. It might require firejail to have some kind of daemon running that watches for the presence of zombie processes in sandboxes. But I'll leave that determination to the firejail developers.

gitea-mirror commented

2026-05-05 08:41:37 -06:00

Author

Owner

@Futureknows commented on GitHub (Feb 22, 2020):

I see, thanks for the detailed explanation. I suppose the simplest workaround would be to force firejail to launch VLC in a new sandbox on each instance. Is this possible from firejail's command line?

@Futureknows commented on GitHub (Feb 22, 2020): I see, thanks for the detailed explanation. I suppose the simplest workaround would be to force firejail to launch VLC in a new sandbox on each instance. Is this possible from firejail's command line?

gitea-mirror commented

2026-05-05 08:41:38 -06:00

Author

Owner

@ghost commented on GitHub (Feb 23, 2020):

I suppose the simplest workaround would be to force firejail to launch VLC in a new sandbox on each instance. Is this possible from firejail's command line?

Not directly no. You can use a simple shell script wrapper to shutdown any lingering VLC sandbox prior to starting a new one. Here's a basic run-down:

name the VLC sandbox for easy killing (firejail --shutdown=vlc)
$ echo "name vlc" >> ${HOME}/.config/firejail/vlc.local
create the wrapper script

$ cat fj.vlc
#!/bin/sh    
## shutdown potentially lingering VLC sandbox
#+ try native shutdown first
firejail --shutdown=vlc 2> /dev/null || _err=1
#+ try fallback via killall
[ "$_err" ] && killall --quiet --ns 0 vlc
## start a new VLC sandbox
if [ -L /usr/local/bin/vlc ]; then
    #+ using the (firecfg generated) firejail symlink
    /usr/local/bin/vlc &
else
    #+ manually
    firejail /usr/bin/vlc &
fi
exit 0

Place fj.vlc (or whatever you named it) somewhere it gets picked-up first by your PATH, e.g. ${HOME}/bin or /usr/local/bin. If you use a firecfg generated ${HOME}/.local/share/applications/vlc.desktop, make sure to edit the Exec= line, now referencing the fj.vlc command.

@ghost commented on GitHub (Feb 23, 2020): > I suppose the simplest workaround would be to force firejail to launch VLC in a new sandbox on each instance. Is this possible from firejail's command line? Not directly no. You can use a simple shell script wrapper to shutdown any lingering VLC sandbox prior to starting a new one. Here's a basic run-down: - name the VLC sandbox for easy killing (firejail --shutdown=vlc) `$ echo "name vlc" >> ${HOME}/.config/firejail/vlc.local` - create the wrapper script ``` $ cat fj.vlc #!/bin/sh ## shutdown potentially lingering VLC sandbox #+ try native shutdown first firejail --shutdown=vlc 2> /dev/null || _err=1 #+ try fallback via killall [ "$_err" ] && killall --quiet --ns 0 vlc ## start a new VLC sandbox if [ -L /usr/local/bin/vlc ]; then #+ using the (firecfg generated) firejail symlink /usr/local/bin/vlc & else #+ manually firejail /usr/bin/vlc & fi exit 0 ``` Place `fj.vlc` (or whatever you named it) somewhere it gets picked-up **first** by your PATH, e.g. ${HOME}/bin or /usr/local/bin. If you use a firecfg generated ${HOME}/.local/share/applications/vlc.desktop, make sure to edit the `Exec=` line, now referencing the `fj.vlc` command.

gitea-mirror commented

2026-05-05 08:41:39 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 6, 2020):

Do we want to implement any zombie handling?

@rusty-snake commented on GitHub (May 6, 2020): Do we want to implement any zombie handling?

gitea-mirror commented

2026-05-05 08:41:39 -06:00

Author

Owner

@Futureknows commented on GitHub (May 8, 2020):

FYI I have noticed it doesn't happen on all systems, so I don't think it's
a high priority.

On Wed, May 6, 2020 at 8:41 AM rusty-snake notifications@github.com wrote:

Do we want to implement any zombie handling?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/netblue30/firejail/issues/3224#issuecomment-624725816,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAS622ZUMWYJZFMWDOSZLLRQGALXANCNFSM4KVBTL7Q
.

@Futureknows commented on GitHub (May 8, 2020): FYI I have noticed it doesn't happen on all systems, so I don't think it's a high priority. On Wed, May 6, 2020 at 8:41 AM rusty-snake <notifications@github.com> wrote: > Do we want to implement any zombie handling? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/netblue30/firejail/issues/3224#issuecomment-624725816>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFAS622ZUMWYJZFMWDOSZLLRQGALXANCNFSM4KVBTL7Q> > . >

gitea-mirror commented

2026-05-05 08:41:40 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 4, 2021):

Has anyone else noticed this behaviour?

When I wrote the wps profiles, I noticed such a behaviour if seccomp was used. There where no violations in the syslog and it had even happen with seccomp.drop @swap.

@rusty-snake commented on GitHub (Jan 4, 2021): > Has anyone else noticed this behaviour? When I wrote the wps profiles, I noticed such a behaviour if seccomp was used. There where no violations in the syslog and it had even happen with `seccomp.drop @swap`.

gitea-mirror commented

2026-05-05 08:41:40 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 4, 2021):

Do we want to implement any zombie handling?

I think we want. It shouldn't be complicated.

@rusty-snake commented on GitHub (Aug 4, 2021): > Do we want to implement any zombie handling? I think we want. It shouldn't be complicated.

gitea-mirror referenced this issue

2026-05-05 10:14:45 -06:00

[PR #2022] [MERGED] discord: added localtime and ld.so.cache to private-etc to fix wrong time and "discord: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory" #4155

Rows
Columns

[GH-ISSUE #3224] Firejail not tearing down sandbox after closing VLC #2022