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

["Marc Aurèle La France" <tsi@tuyoix.net>]

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.