163854 - Race condition checking lock files

Status: RESOLVED DUPLICATE of bug 151188

(Camino Graveyard :: General, defect)

Description

[PaulC]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020820
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020820

It appears that Navigator uses the PID embedded in the lock file symbolic link
(lock -> 0.0.0.0:####) to test whether there is another instance of Navigator
running. There is a potential race condition here if Navigator closes
unexpectedly without clearing the lock file and by the time the user attempts to
restart the system PID has wrapped around such that another process is using
this PID. In this case navigator will refuse to restart and display a message
stating that another instance is running. I assume that Navogator is kist doing
a kill(pid,0) to check if the process exists rather than verifying that it is
actually an instance of Navigator.

Although this may sound unlikely it actually happened to me following a power
outage and I needed to manually delete the lock file to be able to start Navigator.

Reproducible: Always

Steps to Reproduce:
This can be reproduced artificially however the chance of it actually happening
to a user are fairly slim (but definitely possible)

a. Quit Navigator
b. Create a dummy lock file pointing to an existing process:
   $ ln -fs 0.0.0.0:PID lock
c. Attempt to start Navigator
Actual Results:  
Error dialog displayed stating that another instance is running

Expected Results:  
Navigator should attempt to check whether the process indicated by the lockfile
is actually a Navigator instance (possibly by inspecting kvm_getprocs) or at the
least offer an option for deleing the lockfile and continuing.

Comment 1

[Greg K.]

PaulC, is this a problem with Mozilla as well?

Comment 2

[Sören 'Chucker' Kuklau (gone)]

IIRC, this actually happened to me once and I could only get rid of the problem
by restarting.

Comment 3

[saari (gone)]

->pinkerton

Comment 4

[Mike Pinkerton (not reading bugmail)]

ahhh the dreaded lock file. no way i'm touching this one ;)

-> ccarlen

Comment 5

[Brendan Eich [:brendan]]

This is a dup.

/be

*** This bug has been marked as a duplicate of 151188 ***