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
>>
>>
>
>

-- 
Stephan Wiesand
   DESY - DV -                     Phone:   +49 33762 7 7370
   Platanenallee 6                 Fax:     +49 33762 7 7216
   15738 Zeuthen, Germany