All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marc Aurèle La France" <tsi@tuyoix.net>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] Add setsid option to save child process id
Date: Wed, 29 Jan 2025 09:57:09 -0700 (Mountain Standard Time)	[thread overview]
Message-ID: <alpine.WNT.2.20.2501290953590.4996@CLUIJ> (raw)
In-Reply-To: <ez4oc4bocqcilq36ncfjusirdkmt6jkpfvaakrx5qcslzoqj6f@wxu57ze7zutk>

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.

  reply	other threads:[~2025-01-29 16:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-26 17:40 [PATCH] Add setsid option to save child process id Marc Aurèle La France
2025-01-29 12:16 ` Karel Zak
2025-01-29 16:57   ` Marc Aurèle La France [this message]
2025-01-30 18:05     ` Marc Aurèle La France

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=alpine.WNT.2.20.2501290953590.4996@CLUIJ \
    --to=tsi@tuyoix.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.