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