Re: [Qemu-devel] [PATCH] GuestAgent: PIDFILE remains when daemon start fails

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 01/06/2012 04:56 AM, Daniel P. Berrange wrote:
> On Thu, Jan 05, 2012 at 06:18:26PM -0600, Michael Roth wrote:
>> On 01/05/2012 04:26 PM, MATSUDA, Daiki wrote:
>>> Hi, all.
>>>
>>> I am trying QEMU Guest Agent and encountered a small bug. It is that the
>>> PIDFILE remains when daemon start fails. And maybe forgotton to g_free().
>>>
>>> MATSUDA, Daiki
>>>
>>
>> Thanks for the patch. There was some contention in the past about
>> whether or not to clean up pidfiles when there was abnormal
>> termination, but personally I like this approach better.
>
> Yep, this still leaves open the problem of pidfile cleanup when the
> daemon crashes. For libvirtd we recently switched over to a crash-safe
> pidfile acquisition design, that uses fcntl(F_SETLK) to maintain
> exclusive access over the pidfile. With this you don't need to worry
> about forgetting to unlink() on termination, since the POSIX lock is
> automatically released when process exits (or crashes).

Yup, we did the same at some point via lockf(). An argument was made 
that stale PID files from unresolved crashes should stick around, so we 
dropped it. I think we should re-evaluate that decision...libvirt taking 
the same approach is pretty good precedence for me. I don't expect to 
have state from crashed programs interrupting attempts to restart them, 
it's more an unpleasant surprise than a feature, I think.

In any case, we should clean PID files when we know/report the reason 
for the exit, at least. So the patches are good in that regard, but 
unecessary if we go back to the F_SETLK approach, which I'd prefer.

>
> If you're interested in copying the algorithm libvirt uses for pidfiles
> then look at the virPidFileAcquirePath() function, starting line 308,
> and also corresponding virPidFileReleasePath() to (optionally) call
> on shutdown:
>
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virpidfile.c;hb=HEAD
>
> Regards,
> Daniel