[PATCH] Add setsid option to save child process id

[PATCH] Add setsid option to save child process id

[Marc Aurèle La France]

Add an option to save the child's pid into a file.

Marc.

diff -NRapruz -X /etc/diff.excludes util-linux-2.40.4/sys-utils/setsid.1.adoc devel-2.40.4/sys-utils/setsid.1.adoc
--- util-linux-2.40.4/sys-utils/setsid.1.adoc
+++ devel-2.40.4/sys-utils/setsid.1.adoc
@@ -31,6 +31,9 @@ Always create a new process.
 *-w*, *--wait*::
 Wait for the execution of the program to end, and return the exit status of this program as the exit status of *setsid*.

+*-p*, *--pidfile* _file_::
+If forked, write the process id of the program to _file_.
+
 *-V*, *--version*::
 Display version information and exit.

diff -NRapruz -X /etc/diff.excludes util-linux-2.40.4/sys-utils/setsid.c devel-2.40.4/sys-utils/setsid.c
--- util-linux-2.40.4/sys-utils/setsid.c
+++ devel-2.40.4/sys-utils/setsid.c
@@ -14,6 +14,9 @@
  *
  * 2008-08-20 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
  * - if forked, wait on child process and emit its return code.
+ *
+ * 2025-01-25 Marc Aurèle La France <tsi@tuyoix.net>
+ * - If forked, save the child's process id in a file.
  */
 #include <getopt.h>
 #include <stdio.h>
@@ -39,11 +42,12 @@ static void __attribute__((__noreturn__)) usage(void)
 	fputs(_("Run a program in a new session.\n"), out);

 	fputs(USAGE_OPTIONS, out);
-	fputs(_(" -c, --ctty     set the controlling terminal to the current one\n"), out);
-	fputs(_(" -f, --fork     always fork\n"), out);
-	fputs(_(" -w, --wait     wait program to exit, and use the same return\n"), out);
+	fputs(_(" -c, --ctty               set the controlling terminal to the current one\n"), out);
+	fputs(_(" -f, --fork               always fork\n"), out);
+	fputs(_(" -w, --wait               wait program to exit, and use the same return\n"), out);
+	fputs(_(" -p, --pidfile <file>     write child pid to <file>\n"), out);

-	fprintf(out, USAGE_HELP_OPTIONS(16));
+	fprintf(out, USAGE_HELP_OPTIONS(26));

 	fprintf(out, USAGE_MAN_TAIL("setsid(1)"));
 	exit(EXIT_SUCCESS);
@@ -55,14 +59,17 @@ int main(int argc, char **argv)
 	int ctty = 0;
 	pid_t pid;
 	int status = 0;
+	const char *pidpath = NULL;
+	FILE *pidfile;

 	static const struct option longopts[] = {
-		{"ctty", no_argument, NULL, 'c'},
-		{"fork", no_argument, NULL, 'f'},
-		{"wait", no_argument, NULL, 'w'},
-		{"version", no_argument, NULL, 'V'},
-		{"help", no_argument, NULL, 'h'},
-		{NULL, 0, NULL, 0}
+		{"ctty",    no_argument,       NULL, 'c'},
+		{"fork",    no_argument,       NULL, 'f'},
+		{"wait",    no_argument,       NULL, 'w'},
+		{"pidfile", required_argument, NULL, 'p'},
+		{"version", no_argument,       NULL, 'V'},
+		{"help",    no_argument,       NULL, 'h'},
+		{NULL,      0,                 NULL, 0}
 	};

 	setlocale(LC_ALL, "");
@@ -70,7 +77,7 @@ int main(int argc, char **argv)
 	textdomain(PACKAGE);
 	close_stdout_atexit();

-	while ((ch = getopt_long(argc, argv, "+Vhcfw", longopts, NULL)) != -1)
+	while ((ch = getopt_long(argc, argv, "+Vhcfp:w", longopts, NULL)) != -1)
 		switch (ch) {
 		case 'c':
 			ctty=1;
@@ -81,6 +88,9 @@ int main(int argc, char **argv)
 		case 'w':
 			status = 1;
 			break;
+		case 'p':
+			pidpath = optarg;
+			break;

 		case 'h':
 			usage();
@@ -105,6 +115,16 @@ int main(int argc, char **argv)
 			break;
 		default:
 			/* parent */
+			if (pidpath) {
+				pidfile = fopen(pidpath, "w");
+				if (pidfile == NULL)
+					warn(_("cannot open pidfile %s"),
+						pidpath);
+				else {
+					fprintf(pidfile, "%d\n", pid);
+					fclose(pidfile);
+				}
+			}
 			if (!status)
 				return EXIT_SUCCESS;
 			if (wait(&status) != pid)

Re: [PATCH] Add setsid option to save child process id

[Karel Zak]

 Hi Marc,

On Sun, Jan 26, 2025 at 10:40:19AM GMT, Marc Aurèle La France wrote:
> Add an option to save the child's pid into a file.

we usually use Signed-off-by: line in the commit messages.

> @@ -105,6 +115,16 @@ int main(int argc, char **argv)
>  			break;
>  		default:
>  			/* parent */
> +			if (pidpath) {
> +				pidfile = fopen(pidpath, "w");
> +				if (pidfile == NULL)
> +					warn(_("cannot open pidfile %s"),
> +						pidpath);
> +				else {
> +					fprintf(pidfile, "%d\n", pid);
> +					fclose(pidfile);
> +				}
> +			}
>  			if (!status)
>  				return EXIT_SUCCESS;
>  			if (wait(&status) != pid)
 
What is the intended use-case for this feature?

I am unsure if this implementation is too simplistic. It seems that
the file is not deleted after the child process exits. Furthermore,
what would happen if we call multiple setsid instances with the same
pidfile? Would it be better to create the pidfile in the child process
after setsid() and ioctl(), in order to avoid creating the
pidfile in case of an error?

For reference, the code in misc-utils/uuidd.c uses a more advanced
method.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] Add setsid option to save child process id

[Marc Aurèle La France]

On Wed, 2025-Jan-29, Karel Zak wrote:
> On Sun, Jan 26, 2025 at 10:40:19AM GMT, Marc Aurèle La France wrote:
>> Add an option to save the child's pid into a file.

>> @@ -105,6 +115,16 @@ int main(int argc, char **argv)
>>  			break;
>>  		default:
>>  			/* parent */
>> +			if (pidpath) {
>> +				pidfile = fopen(pidpath, "w");
>> +				if (pidfile == NULL)
>> +					warn(_("cannot open pidfile %s"),
>> +						pidpath);
>> +				else {
>> +					fprintf(pidfile, "%d\n", pid);
>> +					fclose(pidfile);
>> +				}
>> +			}
>>  			if (!status)
>>  				return EXIT_SUCCESS;
>>  			if (wait(&status) != pid)

> What is the intended use-case for this feature?

To put various utilities (ping, tcpdump, ad nauseam) in the background and
have a simple way of controlling each instance individually.

> I am unsure if this implementation is too simplistic. It seems that
> the file is not deleted after the child process exits. Furthermore,
> what would happen if we call multiple setsid instances with the same
> pidfile? Would it be better to create the pidfile in the child process
> after setsid() and ioctl(), in order to avoid creating the
> pidfile in case of an error?

> For reference, the code in misc-utils/uuidd.c uses a more advanced
> method.

Repeat after me:

KISS.

Marc.

Re: [PATCH] Add setsid option to save child process id

[Marc Aurèle La France]

On Wed, 2025-Jan-29, Marc Aurèle La France wrote:
> On Wed, 2025-Jan-29, Karel Zak wrote:
>> On Sun, Jan 26, 2025 at 10:40:19AM GMT, Marc Aurèle La France wrote:

It would appear some clarification is in order here.

>>> Add an option to save the child's pid into a file.

>>> @@ -105,6 +115,16 @@ int main(int argc, char **argv)
>>>  			break;
>>>  		default:
>>>  			/* parent */
>>> +			if (pidpath) {
>>> +				pidfile = fopen(pidpath, "w");
>>> +				if (pidfile == NULL)
>>> +					warn(_("cannot open pidfile %s"),
>>> +						pidpath);
>>> +				else {
>>> +					fprintf(pidfile, "%d\n", pid);
>>> +					fclose(pidfile);
>>> +				}
>>> +			}
>>>  			if (!status)
>>>  				return EXIT_SUCCESS;
>>>  			if (wait(&status) != pid)

>> What is the intended use-case for this feature?

> To put various utilities (ping, tcpdump, ad nauseam) in the background and
> have a simple way of controlling each instance individually.

>> I am unsure if this implementation is too simplistic.

Yes, that's what the KISS principle is about.

>> It seems that the file is not deleted after the child process exits.

This could be done, but only if --wait is also specified.

>> Furthermore, what would happen if we call multiple setsid instances
>> with the same pidfile?

Like other things in life, you get what you ask for.

>> Would it be better to create the pidfile in the child process after
>> setsid() and ioctl(), in order to avoid creating the pidfile in case of
>> an error?

>> For reference, the code in misc-utils/uuidd.c uses a more advanced
>> method.

This is not intended to be some default pidfile management mechanism.
Indeed, it cannot be.  As my documentation insert clearly states, a pid is
to be saved into a file.  Full stop.

> Repeat after me:

> KISS.

Thus, what I am accusing you of stands.  You are trying to make this far
more complicated than it needs to be.

Marc.