github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #3100] Ctrl+c on terminal program mpsyt causes unclean termination #1943

New issue

Closed

opened 2026-05-05 08:36:37 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

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

Owner

Originally created by @D-Nice on GitHub (Dec 27, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3100

The regular behaviour on ctrl+c for mpsyt is to gracefully shutdown, and also save whatever session history happened.

When running it in firejail, with or without profile, the exit is unclean. This always results in the session history not being saved, and there being no exit message as with vanilla mpsyt, but instead

Child received signal 2, shutting down the sandbox...

Parent is shutting down, bye...

Sometimes, the terminal it was run in, also ends up 'corrupted' in that it may no longer accept input.

I understand this is likely a symptom of the architecture. One way to get around it is to use the exit keyword, which will allow mpsyt to gracefully exit before the sandbox is terminated.

I thought it worth it to still ask if there is anyway around this, due to ctrl+c being in my muscle memory, and I presume this may affect other terminal applications that have ctrl+c handlers built-in, being skipped.

Originally created by @D-Nice on GitHub (Dec 27, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/3100 The regular behaviour on `ctrl+c` for mpsyt is to gracefully shutdown, and also save whatever session history happened. When running it in firejail, with or without profile, the exit is unclean. This always results in the session history not being saved, and there being no exit message as with vanilla mpsyt, but instead ``` Child received signal 2, shutting down the sandbox... Parent is shutting down, bye... ``` Sometimes, the terminal it was run in, also ends up 'corrupted' in that it may no longer accept input. I understand this is likely a symptom of the architecture. One way to get around it is to use the `exit` keyword, which will allow mpsyt to gracefully exit before the sandbox is terminated. I thought it worth it to still ask if there is anyway around this, due to `ctrl+c` being in my muscle memory, and I presume this may affect other terminal applications that have `ctrl+c` handlers built-in, being skipped.

gitea-mirror

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

closed this issue
added the
information_old
label

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Jan 21, 2020):

I stopped using mps-youtube for a while now, but if memory serves, it uses /q or /quit to exit gracefully. Being terminal based you might try with --ignore="shell none" --ignore=private-bin (or adding ignore shell none and ignore private-bin to your mpsyt.local).

@ghost commented on GitHub (Jan 21, 2020): I stopped using mps-youtube for a while now, but if memory serves, it uses /q or /quit to exit gracefully. Being terminal based you might try with `--ignore="shell none" --ignore=private-bin` (or adding `ignore shell none` and `ignore private-bin` to your mpsyt.local).

gitea-mirror commented

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

Author

Owner

@D-Nice commented on GitHub (Jan 21, 2020):

@glitsj16 already aware of /exit, but /q and /quit are useful to know as well :).

Unfortunately the ignores did not help (put in local conf as mentioned, and I already have an existingo one for mpsyt), otherwise I would close the issue and consider it resolved.

It's not a breaking issue for me at all, but definitely could be an annoyance for certain things, and a known workaround would be useful for this and for other things. Most annoying part really is the unusable shell thereafter.

@D-Nice commented on GitHub (Jan 21, 2020): @glitsj16 already aware of /exit, but /q and /quit are useful to know as well :). Unfortunately the ignores did not help (put in local conf as mentioned, and I already have an existingo one for mpsyt), otherwise I would close the issue and consider it resolved. It's not a breaking issue for me at all, but definitely could be an annoyance for certain things, and a known workaround would be useful for this and for other things. Most annoying part really is the unusable shell thereafter.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Jan 22, 2020):

@D-Nice I can see why it is annoying to end up with a broken shell. The only other suggestion I have on this is to ignore tracelog and adding quiet at the top of the mpsyt.profile. But you might have tried that already. Wen I used mpsyt I had a script that started it in a dedicated terminal that I never used for anything else and I stopped firejailing mpsyt itself, only the custom defined player. Not nice but that at least kept things from breaking on shutting down mpsyt. I'm still clueless as to why this happens in the first place though.

@ghost commented on GitHub (Jan 22, 2020): @D-Nice I can see why it is annoying to end up with a broken shell. The only other suggestion I have on this is to `ignore tracelog` and adding `quiet` at the top of the mpsyt.profile. But you might have tried that already. Wen I used mpsyt I had a script that started it in a dedicated terminal that I never used for anything else and I stopped firejailing mpsyt itself, only the custom defined player. Not nice but that at least kept things from breaking on shutting down mpsyt. I'm still clueless as to why this happens in the first place though.

gitea-mirror commented

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

Author

Owner

@matu3ba commented on GitHub (Apr 10, 2020):

@D-Nice The roughly handling is described here.
You could start with strace to see what stuff happens.
My guess is that the history is not written, but buffered in memory or tmpfiles. That is however the problem of the application.
This post describes the underlying problem in usage of bad specifications/designs.

@glitsj16 Suggestion to tag more information needed.

@matu3ba commented on GitHub (Apr 10, 2020): @D-Nice The roughly handling is described [here](https://unix.stackexchange.com/a/522384). You could start with strace to see what stuff happens. My guess is that the history is not written, but buffered in memory or tmpfiles. That is however the problem of the application. This post describes the underlying [problem](https://unix.stackexchange.com/a/524664) in usage of bad specifications/designs. @glitsj16 Suggestion to tag `more information needed`.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Apr 10, 2020):

@matu3ba Done. I had some email trouble lately and I think I saw another thread you asked me to label. Do you happen to remember which one?

@ghost commented on GitHub (Apr 10, 2020): @matu3ba Done. I had some email trouble lately and I think I saw another thread you asked me to label. Do you happen to remember which one?

gitea-mirror commented

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

Author

Owner

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

I'm closing here due to inactivity, please fell free to reopen if you still have this issue.

@rusty-snake commented on GitHub (May 6, 2020): I'm closing here due to inactivity, please fell free to reopen if you still have this issue.

gitea-mirror referenced this issue

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

[PR #1943] [CLOSED] Krita: Enable python and KDE (ksyscoca) #4138

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1943

No description provided.

Rows
Columns