Re: enbd 2.4.32/kernel 2.6.12.3 pid file problem

Peter T. Breuer wrote:
>"Also sprach u.schmeling:"
>  
>>Maybe this problem is not really related to the above combination.
>>When starting a client I get:
>>nbd/pidfile  8854: <# 140> lockpidfile returning err -16 for lock attempt
>>enbd-client  8854: <#4257> main There is already a enbd-client running.
>>    
>
>
>Did you notice WHICH pid was in the pidfile?
>
>I can only find one call that will look in the pidfile in the client 
>code, and it is in nbd/enbd-client.c:
>
>    // PTB (re) make our (session master) pidfile with our pid inside 
>    // after fork
>    if (client->cid) {
>        struct nbd_pidfile * pidfile = &client->pidfile;
>        void removepidfile () {
>            pidfile->unlock (pidfile);
>        };
>
>        err = pidfile->lock (pidfile);
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        if (err < 0) {
>            // PTB this probably better not be deadly, so fakeroot can 
>            // launch
>
>
>This is right in main(). The main code forks and dies as part of the 
>go-daemon procedure, and its child does the pidfile check.  So it can't
>be a race with ITSELF.
>
>The check code itself only will complain if the pid already in the pidfile
>is actually running at the time. 
>
>
>I would GUESS that you are running this code autmatically at boot
>and that sometimes at reboot the old pid in the pidfile is a valid pid
>for a new running process.
>
>Is that it?
>
>Peter
>
>_______________________________________________
>ENBD mailing list
>[email protected]
>http://lists.community.tummy.com/mailman/listinfo/enbd
>  
No that isn't the way it happens. Before starting I have removed all pid 
files and the problem occurs too. So I have added a printout of the 
related pid, when the problem occurs. Will try to add additional 
printouts, so that you can see what happens during this day.
regards Uwe