Hallo Urs,

On Fri, 4 Aug 2006, Urs Beyerle wrote:

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

Yes it is :-(  "Improvements" all over the place...

Cheers,
	Stephan
 
> 
> 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
> > > >
> > > >
> > >
> > >
> >
> 

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