[GH-ISSUE #725] Firejailed processes not always close properly

gitea-mirror commented

2026-05-05 05:57:44 -06:00

Owner

Originally created by @curiosity-seeker on GitHub (Aug 17, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/725

I'm running Firejail 0.9.40 on Fedora 24. Sometimes I notice that for firejailed programmes which I close processes are still running.

Example: Today I ran Thunderbird. firejail --tree shows:

9276:hank:/usr/bin/firejail /usr/bin/thunderbird 
  9277:hank:/usr/bin/firejail /usr/bin/thunderbird 
    9732:hank:gpg-agent --homedir /home/hank/.gnupg --use-standard-socket --daemon

Then I close Thunderbird and start it again after a while. Now firejail --tree shows:

9276:hank:/usr/bin/firejail /usr/bin/thunderbird 
  9277:hank:/usr/bin/firejail /usr/bin/thunderbird 
    9732:hank:gpg-agent --homedir /home/hank/.gnupg --use-standard-socket --daemon 
10897:hank:/usr/bin/firejail /usr/bin/thunderbird 
  10898:hank:/usr/bin/firejail /usr/bin/thunderbird 
    10900:hank:/usr/lib64/thunderbird/thunderbird

This is also confirmed, e.g., in ksysguard.

I had noticed something similar if I open a PDF file in Thunderbird with Okular. After closing Okular the respective processes are still shown in firejail -tree.

I'm sorry for not being more specific as this observation is not always reproducible. My impression is that this only occurs with Thunderbird and Okular.

Originally created by @curiosity-seeker on GitHub (Aug 17, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/725 I'm running Firejail 0.9.40 on Fedora 24. Sometimes I notice that for firejailed programmes which I close processes are still running. Example: Today I ran Thunderbird. firejail --tree shows: ``` 9276:hank:/usr/bin/firejail /usr/bin/thunderbird 9277:hank:/usr/bin/firejail /usr/bin/thunderbird 9732:hank:gpg-agent --homedir /home/hank/.gnupg --use-standard-socket --daemon ``` Then I close Thunderbird and start it again after a while. Now firejail --tree shows: ``` 9276:hank:/usr/bin/firejail /usr/bin/thunderbird 9277:hank:/usr/bin/firejail /usr/bin/thunderbird 9732:hank:gpg-agent --homedir /home/hank/.gnupg --use-standard-socket --daemon 10897:hank:/usr/bin/firejail /usr/bin/thunderbird 10898:hank:/usr/bin/firejail /usr/bin/thunderbird 10900:hank:/usr/lib64/thunderbird/thunderbird ``` This is also confirmed, e.g., in ksysguard. I had noticed something similar if I open a PDF file in Thunderbird with Okular. After closing Okular the respective processes are still shown in firejail -tree. I'm sorry for not being more specific as this observation is not always reproducible. My impression is that this only occurs with Thunderbird and Okular.

gitea-mirror

2026-05-05 05:57:44 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 05:57:50 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 18, 2016):

Can you do a test on the latest git version?

@netblue30 commented on GitHub (Aug 18, 2016): Can you do a test on the latest git version?

gitea-mirror commented

2026-05-05 05:57:53 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Aug 18, 2016):

Sure! I just installed the copr build. I will test it and report!

@curiosity-seeker commented on GitHub (Aug 18, 2016): Sure! I just installed the copr build. I will test it and report!

gitea-mirror commented

2026-05-05 05:57:54 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Aug 18, 2016):

With the copr version (0.9.42-1.201608171910git20e643e.fc24) the problem still exists. After closing Thunderbird, waiting a couple of minutes and starting it again, firejail --tree shows:

3841:hank:/usr/bin/firejail /usr/bin/thunderbird 
  3842:hank:/usr/bin/firejail /usr/bin/thunderbird 
    4310:hank:gpg-agent --homedir /home/hank/.gnupg --use-standard-socket --daemon 
8117:hank:/usr/bin/firejail /usr/bin/thunderbird 
  8118:hank:/usr/bin/firejail /usr/bin/thunderbird 
    8120:hank:/usr/lib64/thunderbird/thunderbird

Here's what ksysguard show:

@curiosity-seeker commented on GitHub (Aug 18, 2016): With the copr version (0.9.42-1.201608171910git20e643e.fc24) the problem still exists. After closing Thunderbird, waiting a couple of minutes and starting it again, firejail --tree shows: ``` 3841:hank:/usr/bin/firejail /usr/bin/thunderbird 3842:hank:/usr/bin/firejail /usr/bin/thunderbird 4310:hank:gpg-agent --homedir /home/hank/.gnupg --use-standard-socket --daemon 8117:hank:/usr/bin/firejail /usr/bin/thunderbird 8118:hank:/usr/bin/firejail /usr/bin/thunderbird 8120:hank:/usr/lib64/thunderbird/thunderbird ``` Here's what ksysguard show: ![thunderbird](https://cloud.githubusercontent.com/assets/14075215/17784613/6e58f6f4-657d-11e6-83d8-679d80e3cbec.png)

gitea-mirror commented

2026-05-05 05:57:57 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 18, 2016):

What version of Thunderbird do you have? Here on Debian stable it seems to close down nicely.

@netblue30 commented on GitHub (Aug 18, 2016): What version of Thunderbird do you have? Here on Debian stable it seems to close down nicely.

gitea-mirror commented

2026-05-05 05:58:01 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Aug 19, 2016):

I'm using v. 45.2.0

@curiosity-seeker commented on GitHub (Aug 19, 2016): I'm using v. 45.2.0

gitea-mirror commented

2026-05-05 05:58:04 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 20, 2016):

I'll have to look into it, thanks.

@netblue30 commented on GitHub (Aug 20, 2016): I'll have to look into it, thanks.

gitea-mirror commented

2026-05-05 05:58:06 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Aug 20, 2016):

Thanks! If it happens - and it doesn't every time as mentioned earlier - and I close Thunderbird again, the latest processes (in above example PID 8117,8118,8210) are terminated properly. What's still running are the PIDs 3841 and 3842.

@curiosity-seeker commented on GitHub (Aug 20, 2016): Thanks! If it happens - and it doesn't every time as mentioned earlier - and I close Thunderbird again, the latest processes (in above example PID 8117,8118,8210) are terminated properly. What's still running are the PIDs 3841 and 3842.

gitea-mirror commented

2026-05-05 05:58:08 -06:00

Author

Owner

@SYN-cook commented on GitHub (Mar 6, 2017):

I can confirm this for Debian Stretch KDE. Also for me only Thunderbird and Okular are affected.

With Okular, but as far as I remember not with Thunderbird, I have the same issue on Debian Jessie Mate.

When I start Okular with firejail --trace okular and close the window, the application keeps running until I press Ctrl+C:

...
2:okular:fopen /etc/rpc:0x14e8ca0
^C
Parent received signal 2, shutting down the child process...

Parent is shutting down, bye...

Child received signal 15, shutting down the sandbox...
klauncher: Exiting on signal 15

If the first "hanging" instance is not terminated, I can launch a normal behaving second one, and the output of firejail --tree then looks like

4502:user:firejail okular 
  4503:user:firejail okular 
    4510:user:kdeinit4: kdeinit4 Runnin e 
      4511:user:kdeinit4: klauncher [kdei e 
    4513:user:kdeinit4: kded4 [kdeinit]   
4534:user:firejail okular 
  4535:user:firejail okular 
    4537:user:okular

on Debian Jessie Mate.

Unfortunately I don't see this always, and I didn't yet recognize a trigger.

@SYN-cook commented on GitHub (Mar 6, 2017): I can confirm this for Debian Stretch KDE. Also for me only Thunderbird and Okular are affected. With Okular, but as far as I remember not with Thunderbird, I have the same issue on Debian Jessie Mate. When I start Okular with `firejail --trace okular` and close the window, the application keeps running until I press Ctrl+C: ``` ... 2:okular:fopen /etc/rpc:0x14e8ca0 ^C Parent received signal 2, shutting down the child process... Parent is shutting down, bye... Child received signal 15, shutting down the sandbox... klauncher: Exiting on signal 15 ``` If the first "hanging" instance is not terminated, I can launch a normal behaving second one, and the output of `firejail --tree` then looks like ``` 4502:user:firejail okular 4503:user:firejail okular 4510:user:kdeinit4: kdeinit4 Runnin e 4511:user:kdeinit4: klauncher [kdei e 4513:user:kdeinit4: kded4 [kdeinit] 4534:user:firejail okular 4535:user:firejail okular 4537:user:okular ``` on Debian Jessie Mate. Unfortunately I don't see this always, and I didn't yet recognize a trigger.

gitea-mirror commented

2026-05-05 05:58:10 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jul 17, 2017):

@rekixex : It doesn't happen anymore for me with Okular. Note that I'm using v. 1.0.3 with KDE Frameworks 5.36.0 and Qt 5.7.1 on Fedora 26. And I haven't observed this problem for Thunderbird anymore, either (v. 52.2.1).

However, I'm using a modified profile for both applications. For Thunderbird:

noblacklist ~/.gnupg
mkdir ~/.gnupg
whitelist ~/.gnupg

noblacklist ~/.thunderbird
mkdir ~/.thunderbird
whitelist ~/.thunderbird

noblacklist ~/.cache/thunderbird
mkdir ~/.cache/thunderbird
whitelist ~/.cache/thunderbird

whitelist ~/.config/mimeapps.list
read-only ~/.config/mimeapps.list
whitelist ~/.local/share/applications
read-only ~/.local/share/applications

whitelist ${HOME}/Downloads
whitelist ${HOME}/Uploads

include /etc/firejail/disable-common.inc
include /etc/firejail/disable-devel.inc
include /etc/firejail/disable-passwdmgr.inc
include /etc/firejail/disable-programs.inc

include /etc/firejail/whitelist-common.inc

caps.drop all
netfilter
nonewprivs
noroot
protocol unix,inet,inet6,netlink
seccomp
tracelog

private-dev

noexec ${HOME}
noexec /tmp

And for Okular:

ignore private-tmp
include /etc/firejail/okular.profile

noexec ${HOME}
noexec /tmp
noexec /media

Btw., in Thunderbird I selected xdg-open as the default helper application for all file types.

@curiosity-seeker commented on GitHub (Jul 17, 2017): @rekixex : It doesn't happen anymore for me with Okular. Note that I'm using v. 1.0.3 with KDE Frameworks 5.36.0 and Qt 5.7.1 on Fedora 26. And I haven't observed this problem for Thunderbird anymore, either (v. 52.2.1). However, I'm using a modified profile for both applications. For Thunderbird: ``` noblacklist ~/.gnupg mkdir ~/.gnupg whitelist ~/.gnupg noblacklist ~/.thunderbird mkdir ~/.thunderbird whitelist ~/.thunderbird noblacklist ~/.cache/thunderbird mkdir ~/.cache/thunderbird whitelist ~/.cache/thunderbird whitelist ~/.config/mimeapps.list read-only ~/.config/mimeapps.list whitelist ~/.local/share/applications read-only ~/.local/share/applications whitelist ${HOME}/Downloads whitelist ${HOME}/Uploads include /etc/firejail/disable-common.inc include /etc/firejail/disable-devel.inc include /etc/firejail/disable-passwdmgr.inc include /etc/firejail/disable-programs.inc include /etc/firejail/whitelist-common.inc caps.drop all netfilter nonewprivs noroot protocol unix,inet,inet6,netlink seccomp tracelog private-dev noexec ${HOME} noexec /tmp ``` And for Okular: ``` ignore private-tmp include /etc/firejail/okular.profile noexec ${HOME} noexec /tmp noexec /media ``` Btw., in Thunderbird I selected xdg-open as the default helper application for all file types.

gitea-mirror commented

2026-05-05 05:58:12 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jul 19, 2017):

@rekixex : I think it's not surprising that you cannot access /etc/firejail/okular.profile. You're using the Firejail git version which installs by default to /usr/local. Whereas I install it using

./configure --prefix=/usr

Hence, the path to your profiles is different (I believe it is /usr/local/etc/firejail/okular.profile).

Anyways, can you show us what firejail --tree reports when you start Okular and when you close it?

@curiosity-seeker commented on GitHub (Jul 19, 2017): @rekixex : I think it's not surprising that you cannot access `/etc/firejail/okular.profile`. You're using the Firejail git version which installs by default to `/usr/local`. Whereas I install it using `./configure --prefix=/usr` Hence, the path to your profiles is different (I believe it is `/usr/local/etc/firejail/okular.profile`). Anyways, can you show us what `firejail --tree` reports when you start Okular and when you close it?

gitea-mirror commented

2026-05-05 05:58:15 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 11, 2017):

~~Specifically regarding Okular: It should help launching kdeinit4 once normally, outside a sandbox. This could be done for example during session startup.~~

@smitsohu commented on GitHub (Oct 11, 2017): ~~Specifically regarding Okular: It should help launching kdeinit4 once normally, outside a sandbox. This could be done for example during session startup.~~

gitea-mirror commented

2026-05-05 05:58:17 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 12, 2017):

Specifically regarding Okular: It should help to launch kdeinit4 inside a Firejail sandbox, and keep this instance running in the background. This could be done for example during session startup.

EDIT: Admittedly this "solution" is not very different from what was reported here as bug, but it was suggested with #1599 in mind. It has some advantage when not all KDE apps run in Firejail automatically, and it allows to confine the process better through a tailored profile (that still needs to be written).

@smitsohu commented on GitHub (Oct 12, 2017): Specifically regarding Okular: It should help to launch kdeinit4 inside a Firejail sandbox, and keep this instance running in the background. This could be done for example during session startup. EDIT: Admittedly this "solution" is not very different from what was reported here as bug, but it was suggested with #1599 in mind. It has some advantage when not all KDE apps run in Firejail automatically, and it allows to confine the process better through a tailored profile (that still needs to be written).

gitea-mirror commented

2026-05-05 05:58:20 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 21, 2019):

I don't really think we have a proper solution for this besides working around things on an app-specific level. I'll close this for now since it feels like we should be targeting known offenders, as it were, in separate issues (if people are running into them). Feel free to re-open if you feel that we should attempt to solve this more generally.

@chiraag-nataraj commented on GitHub (May 21, 2019): I don't really think we have a proper solution for this besides working around things on an app-specific level. I'll close this for now since it feels like we should be targeting known offenders, as it were, in separate issues (if people are running into them). Feel free to re-open if you feel that we _should_ attempt to solve this more generally.

gitea-mirror referenced this issue

2026-05-05 10:05:15 -06:00

[PR #490] [MERGED] Mark skipped tests differently #3643

Rows
Columns

[GH-ISSUE #725] Firejailed processes not always close properly #490