"D. Stimits" schrieb:
>
> Seth Mos wrote:
> >
> > At 01:00 12-9-2001 -0600, D. Stimits wrote:
> > >I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based
> > >(root is XFS). I had a crash at the moment I attempted to start login as
> > >a regular user (home is also XFS). It seems that ~/.ICEauthority is
> > >written each session when gdm/gnome is used for the login session, and
> > >that a check is done for whether or not .ICEauthority can be locked.
> > >After a crash, the file is empty (this is ok, it's the metadata versus
> > >full journal thing, it isn't an issue), since the crash occurs during
> > >that file write. However, after coming back up, X11 will fail due to an
> > >inability to lock the file. A question occurs here, whether lock data or
> > >whatever information is used to determine if a file can be locked, is
> > >part of the filesystem journaling? Or is this a separate issue that
> > >can't be dealth with by journaling filesystems? Is there any way XFS,
> > >coming back after a crash, can remove stale locks or bogus locks? I have
> > >no idea if this is entirely just coincidence it occurs, or if XFS itself
> > >can help recover under such circumstances.
At least you're not alone, I was having the same problem. Did you really
have a kernel crash? I don't rember what happened in my case but I
thought I was upgrading some RPM's and when I rebooted next time I just
couldn't login. IIRC I did not have a kernel crash.
-Simon
> >
> > Most of the time lock files are just empty files that get removed when they
> > are done.
> > Netscape also used to do this. But since a lock file might have 0 bytes
> > size it will be committed to disk very fast and journaling or not the file
> > will probably survive a reboot.
> >
> > Cheers
> >
> > --
> > Seth
> > Every program has two purposes one for which
> > it was written and another for which it wasn't
> > I use the last kind.
>
> In this case the file is .ICEauthority, not related to Netscape. What I
> am thinking about is fcntl(). I'm wondering about how these are
> implemented: F_GETLK, F_SETLK and F_SETLKW. If fcntl locks depend on
> file structures or metadata, or if the file itself has nothing to do
> with fcntl? The complaint after failure would seemt to be that it can't
> set a lock, which is not necessarily the same as file existence.
> Permissions do not seem to be the problem either. Is the filesystem
> cooperating with fcntl, and doing the lock storage? Or is this
> determined in some other way? If the filesystem maintains metadata on
> locks, then it seems that they should be discarded upon recovery. I'm
> not concerned with custom schemes like the one you mention (PostgreSQL
> does this, and it annoys me that after any crash I have to delete the
> postmaster.pid file...yet "/etc/rc.d/init.d/postgresql status" knows
> that the "subsystem is locked but postmaster is not running", and it is
> too stupid to forcibly remove the lock file).
>
> D. Stimits, stimits@xxxxxxxxxx
|