On Tue, May 07, 2019 at 09:39:01PM +0200, Max Reitz wrote: > On 07.05.19 21:30, Eric Blake wrote: > > On 5/7/19 1:36 PM, Max Reitz wrote: > >> --fork is a bit boring if there is no way to get the child's PID. This > >> option helps. > >> > >> Signed-off-by: Max Reitz <mre...@redhat.com> > >> --- > >> qemu-nbd.c | 29 +++++++++++++++++++++++++++++ > >> qemu-nbd.texi | 2 ++ > >> 2 files changed, 31 insertions(+) > >> > > > >> @@ -111,6 +112,7 @@ static void usage(const char *name) > >> " specify tracing options\n" > >> " --fork fork off the server process and exit the > >> parent\n" > >> " once the server is running\n" > >> +" --pid-file=PATH store the server's process ID in the given > >> file\n" > > > > Should --pid-file imply --fork, or be an error if --fork was not > > supplied? As coded, it writes a pid file regardless of --fork, even > > though it is less obvious that it is useful in that case. I don't have a > > strong preference (there doesn't seem to be a useful consensus on what > > forking daemons should do), but it would at least be worth documenting > > the intended action (even if that implies a tweak to the patch to match > > the intent). > > I think the documentation is pretty clear. It stores the server's PID, > whether it has been forked or not. > > I don't think we would gain anything from forbidding --pid-file without > --fork, would we?
Indeed, use of --pid-file should be independant of --fork, as a mgmt app may have already forked it into the background, and merely want to get the pidfile Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
