John Fischer wrote: > The Mozilla/Firefox example is a very good one. The lock file > that you are pointing out is designed to do exactly what it > is doing. It is attempting to prevent multiple copies of the > tool from running.
It is exactly the right example to use. The "Mozilla Failure" is a Denial of Service one - if Mozilla crashes (which it does, sometimes frequently), the lockfile is not removed, and then new instances won't start - even though there is no other instance to guard against. If the lock file handling was "smarter", it would notice that the lock file was stale and invalid, and allow the user to override it. This is the "problem with lock files" that the guideline is trying to address - not the fact that there are lockfiles in the first place. The Mozilla problem is so bad that IT/OPS has a GNOME menu item on all its corporate desktop installs to "remove Mozilla lockfiles". It did this because the support call volume was huge - hundreds of service tickets daily saying "I can't start a browser!" all root caused to a brain dead lockfile scheme. -John
