Re: [Qemu-devel] [PATCH v3] qemu-nbd: Implement socket activation.

[Richard W.M. Jones]

On Fri, Feb 03, 2017 at 10:58:15AM -0800, Paolo Bonzini wrote:
> On 03/02/2017 10:56, Richard W.M. Jones wrote:
> > On Fri, Feb 03, 2017 at 09:31:43AM -0800, Paolo Bonzini wrote:
> >> On 03/02/2017 09:09, Richard W.M. Jones wrote:
> >>> +    if (fork_process) {
> >>> +        return "Fork (--fork) can't be used with socket activation";
> >>> +    }
> >>
> >> Why not?  You could have a Type=forking foo.service, which makes little
> >> sense but would work.
> > 
> > The answer, I think, is because systemd will lose track of the PID of
> > the qemu-nbd process.  This would be important because systemd can
> > kill a socket-activated service which is idle.
> > 
> > Normally you would work around that by using PIDFile=... in the unit
> > file, but it looks like qemu-nbd doesn't support pid files.
> 
> PIDFile is recommended indeed but GuessMainPID=yes (the default for no
> PIDFile) should work, since qemu-nbd only has one parent process.

Another reason:

I think that the --fork option is mainly intended for command line use
of qemu-nbd.  If you're running qemu-nbd from a program there's no
real reason to use --fork, since you can control the fork process
better yourself.

LISTEN_PID isn't settable from the command line.  It's also not
settable from a shell script (as far as I can tell when I was trying
to write a shell script to test nbdkit).  It has to be set between the
fork and exec calls, because it is set to the qemu-nbd PID.

So I don't think --fork and socket activation are really features that
it makes any sense to mix.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html