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