Hallo,

This looks nice!

Since I had the "lock problem" several time today (thunderbird and 
firefox) - and it is really annoying - I will roll out this for testing 
at PSI for firefox and thunderbird.

Is seamonkey also affected by the "lock problem"?


Thanks

    Urs




Stephan Wiesand wrote:
> Hallo,
>
> thanks. Simple and effective. Folks have learned to check for the lock 
> file, but hardly expect the hidden one. I think I'm going to roll this 
> out
> as /usr/lib/firefox-1.5.0.5/init.d/S01parentlock .
>
> Thanks again,
>     Stephan
>
> On Thu, 3 Aug 2006, Gerd Heide wrote:
>
>> Hallo,
>>
>> my workaround is, included in /usr/bin/firefox:
>>
>> [ -e  $HOME/.mozilla/firefox/profiles.ini ] &&
>>  for i in $(grep Name= $HOME/.mozilla/firefox/profiles.ini | sed 
>> s/Name=//)
>>    do
>>      [ ! -L $HOME/.mozilla/firefox/*.$i/lock -a -e 
>> $HOME/.mozilla/firefox/*.$i/.parentlock ] &&
>>      rm -f $HOME/.mozilla/firefox/*.$i/.parentlock
>>    done
>>
>>
>> On Wed, 2 Aug 2006, Stephan Wiesand wrote:
>>
>>> Date: Wed, 02 Aug 2006 19:53:34 +0200 (CEST)
>>> From: Stephan Wiesand <[log in to unmask]>
>>> To:  <[log in to unmask]>
>>> Subject: firefox (thunderbird) 1.5 problems with ~ in AFS (NFS, 
>>> CIFS...)
>>>
>>> Hi All,
>>>
>>> there are problems with the latest firefox if user home directories
>>> reside in AFS. See
>>>
>>>   https://grand.central.org/rt/index.html?q=31818
>>>
>>> and
>>>
>>>   https://bugzilla.mozilla.org/show_bug.cgi?id=318801
>>>
>>> Short story: there were locking changes that seem to require 100% POSIX
>>> compliant behaviour of the filesystem ~/.mozilla resides on. At least
>>> if ~ resides in AFS space, a lock on a file called ".parentlock" in the
>>> active profile directory is not released reliably when firefox exits,
>>> leading to a dialog box saying something to the effect of "some firefox
>>> process is already running, and you have to get rid of it before you
>>> can start another one", even if there's definitely no such process
>>> accessing the home directory on any system.
>>>
>>> AFS users who haven't seen this yet can simply remove the "k" bit from
>>> their firefox profile directory to make this 100% reproducible. 
>>> Otherwise,
>>> the problem shows up randomly only.
>>>
>>> The URLs above prove that both the OpenAFS project (NB the problem 
>>> occurs
>>> with 1.2.13 clients on SL3 as well as 1.4.1 clients on SL4, and to my
>>> knowledge hasn't been fixed in any OpenAFS release including the 1.5
>>> development branch) and the mozilla project have known about the 
>>> problem
>>> for 8 months, and it still exists. In addition, it seems to affect
>>> thunderbird as well, and at least NFS and CIFS besides AFS.
>>>
>>> Hence I guess we're not the only site in need of a fix or at least a
>>> workaround.
>>>
>>> I can imagine dealing with the problem in the following ways:
>>>
>>>  1) Try the patch from comment #29 to the bugzilla.mozilla.org bug
>>>     (use symlinks instead of fcntl() for "locking"). Maybe make it
>>>     unconditional and thus much simpler.
>>>  2) Educate all my users how to delete the .parentlock file if 
>>> necessary.
>>>  3) Tell all my users to make
>>>       ~/.mozilla/<whatever their profile>/.parentlock
>>>     a symlink to a file in /tmp.
>>>  4) Do the same transparently with some scripting in one of the
>>>     firefox wrappers, or using the "init.d" functionality provided
>>>     by one of them, creating the tmp-file in a secure fashion if
>>>     needed.
>>>
>>> The last one is probably best, but it's also a bit of work. The script
>>> would have to do something like this:
>>>
>>>  o find all .parentlock files in ~/.mozilla
>>>    (since we don;t know which profile is going to be used)
>>>  o if they're symlinks, and point to some file in /tmp, and that
>>>    file exists and is owned by $USER, do nothing
>>>  o if they're symlinks, point to some file in /tmp, and that
>>>    file exists but is not owned by USER, OR
>>>      o if they're not symlinks OR
>>>      o if they don't point into /tmp, delete (rename?) them
>>>    create a unique file in /tmp and replace them by symlinks to those
>>>
>>>
>>> I sincerely hope someone on this list has a better and more failsafe
>>> idea...
>>>
>>> How are other AFS sites dealing with this? Jarek, Jan, Connie, Troy,..?
>>>
>>> Cheers,
>>>     Stephan
>>>
>>>
>>
>>
>