Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: --json-status-fd could provide pid of command? #553

Open
teleclimber opened this issue Feb 9, 2023 · 4 comments · May be fixed by #576
Open

Feature request: --json-status-fd could provide pid of command? #553

teleclimber opened this issue Feb 9, 2023 · 4 comments · May be fixed by #576

Comments

@teleclimber
Copy link

--json-status-fd gives a child-pid value, which is handy. In a lot of situations that is the pid of the COMMAND you're running in the sandbox.

But when run with --unshare-pid (and maybe others) bwrap forks itself and child-pid references the fork. I would like a way of getting the pid of the COMMAND. Could this be added to the JSON output?

Thanks.

@smcv
Copy link
Collaborator

smcv commented Feb 23, 2023

If this is achievable, I'd be happy to review a pull request. The easiest way to work out whether this is achievable or not would be to try to implement it and see what happens.

@WGH-
Copy link

WGH- commented Apr 17, 2023

A use case example: you might want to send SIGTERM to give your program a chance to terminate gracefully. However, child-pid is wrong pid to send signals to when bwrap runs pid 1.

WGH- added a commit to WGH-/bubblewrap that referenced this issue Apr 17, 2023
In cases where bwrap runs its own additional PID 1 process (e.g.
--unshare-pid), child-pid used to be the PID of that process, not the
PID of the user-specified COMMAND.

This is inconvenient as the user might want to send e.g. SIGTERM to the
command to give it a chance to exit gracefully.

Closes containers#553
WGH- added a commit to WGH-/bubblewrap that referenced this issue Apr 17, 2023
In cases where bwrap runs its own additional PID 1 process (e.g.
--unshare-pid), child-pid is the PID of that process, not the
PID of the user-specified COMMAND.

This is inconvenient as the user might want to send e.g. SIGTERM to the
command to give it a chance to exit gracefully.

Closes containers#553
@WGH- WGH- linked a pull request Apr 17, 2023 that will close this issue
WGH- added a commit to WGH-/bubblewrap that referenced this issue Apr 17, 2023
In cases where bwrap runs its own additional PID 1 process (e.g.
--unshare-pid), child-pid is the PID of that process, not the
PID of the user-specified COMMAND.

This is inconvenient as the user might want to send e.g. SIGTERM to the
command to give it a chance to exit gracefully.

Closes containers#553

Signed-off-by: WGH <wgh@torlan.ru>
@mcatanzaro
Copy link

I think we'll need this to fix this WebKit bug.

If this is achievable, I'd be happy to review a pull request. The easiest way to work out whether this is achievable or not would be to try to implement it and see what happens.

See #576 (and thank you!).

WGH- added a commit to WGH-/bubblewrap that referenced this issue Jun 11, 2024
In cases where bwrap runs its own additional PID 1 process (e.g.
--unshare-pid), child-pid is the PID of that process, not the
PID of the user-specified COMMAND.

This is inconvenient as the user might want to send e.g. SIGTERM to the
command to give it a chance to exit gracefully.

Closes containers#553

Signed-off-by: WGH <wgh@torlan.ru>
@mcatanzaro
Copy link

I think we'll need this to fix this WebKit bug.

(We wound up not needing it.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants