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.
