From: Kiran Rangoon <kiranrangoon0@gmail.com>
To: util-linux@vger.kernel.org
Cc: kzak@redhat.com, Kiran Rangoon <kiranrangoon0@gmail.com>
Subject: [Patch V3 3/4] unshare: document --forward-signals in man page
Date: Fri, 16 Jan 2026 12:06:47 -0500 [thread overview]
Message-ID: <20260116170648.26439-4-kiranrangoon0@gmail.com> (raw)
In-Reply-To: <20260116170648.26439-1-kiranrangoon0@gmail.com>
Add documentation for the new --forward-signals option, explaining
its use case (graceful shutdown during reboot/system management)
and interaction with the --fork option.
Signed-off-by: Kiran Rangoon <kiranrangoon0@gmail.com>
---
sys-utils/unshare.1.adoc | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/sys-utils/unshare.1.adoc b/sys-utils/unshare.1.adoc
index 1d1fd68f8..888928147 100644
--- a/sys-utils/unshare.1.adoc
+++ b/sys-utils/unshare.1.adoc
@@ -81,6 +81,19 @@ Create a new time namespace. If _file_ is specified, then the namespace is made
*-f*, *--fork*::
Fork the specified _program_ as a child process of *unshare* rather than running it directly. This is useful when creating a new PID namespace. Note that when *unshare* is waiting for the child process, then it ignores *SIGINT* and *SIGTERM* and does not forward any signals to the child. It is necessary to send signals to the child process.
+*--forward-signals*::
+Forward *SIGTERM* and *SIGINT* signals received by the parent *unshare* process to the child process.
+When this option is not specified, *unshare* ignores these signals while waiting for the child process
+to exit (the default behavior since util-linux 2.36). This allows the parent to remain alive while
+the child process handles the signals.
++
+This option is useful when the parent *unshare* process will receive *SIGTERM* or *SIGINT* signals
+(for example, during system reboot or from a process manager), and you want the child process to
+be notified of graceful shutdown requests so it can perform cleanup operations. If your child
+process has signal handlers (such as shell trap handlers), enabling this option allows them to execute.
++
+This option implies *--fork*.
+
*--keep-caps*::
When the *--user* option is given, ensure that capabilities granted in the user namespace are preserved in the child process.
--
2.47.3
next prev parent reply other threads:[~2026-01-16 17:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 18:31 [PATCH 0/5] unshare: fix signal forwarding to child processes Kiran Rangoon
2026-01-08 18:31 ` [PATCH 1/5] unshare: add global child_pid variable for signal forwarding Kiran Rangoon
2026-01-08 18:31 ` [PATCH 2/5] unshare: add signal forwarding handler Kiran Rangoon
2026-01-08 18:31 ` [PATCH 3/5] unshare: replace signal blocking with signal handlers Kiran Rangoon
2026-01-08 18:31 ` [PATCH 4/5] unshare: store child PID in global variable Kiran Rangoon
2026-01-08 18:31 ` [PATCH 5/5] unshare: handle EINTR in waitpid loop Kiran Rangoon
2026-01-12 14:05 ` [PATCH 0/5] unshare: fix signal forwarding to child processes Karel Zak
2026-01-13 17:29 ` [Patch V2 0/4] " Kiran Rangoon
2026-01-13 17:29 ` [V2 1/4] unshare: add --forward-signals option to argument parser Kiran Rangoon
2026-01-13 17:29 ` [V2 2/4] unshare: implement signal forwarding when --forward-signals is used Kiran Rangoon
2026-01-13 17:29 ` [V2 3/4] unshare: document --forward-signals in man page Kiran Rangoon
2026-01-13 17:29 ` [V2 4/4] tests: add tests for unshare --forward-signals Kiran Rangoon
2026-01-16 17:06 ` [PATCH V3 0/4] unshare: add --forward-signals option Kiran Rangoon
2026-01-16 17:06 ` [Patch V3 1/4] unshare: add --forward-signals option to argument parser Kiran Rangoon
2026-01-16 17:06 ` [Patch V3 2/4] unshare: implement signal forwarding when --forward-signals is used Kiran Rangoon
2026-01-16 17:06 ` Kiran Rangoon [this message]
2026-01-16 17:06 ` [Patch V3 4/4] tests: add tests for unshare --forward-signals Kiran Rangoon
2026-01-21 8:37 ` [PATCH V3 0/4] unshare: add --forward-signals option Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260116170648.26439-4-kiranrangoon0@gmail.com \
--to=kiranrangoon0@gmail.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox