Michel Dänzer <daenzer@debian.org> writes: > > After booting, when I logged in from gdm, I first got an error from > > `gconf' than it couldn't lock this file: ... > > Hitting `OK' just went back to gdm, and logging again yielded the same > > result. Judging from the name, I figured it was just a lock file, and > > could be removed, so I removed it and tried logging it again. Whoops. > > Any interesting gconf related messages in log files in /var/log/ ? (use > something like zgrep -l gconf /var/log/*log* to check) There are tons of messages from gconf, but most are in an unknown coding system -- I normally log in using `EUC-JP' but these messages don't seem to be in EUC-JP, nor UTF-8, or at least emacs' decoder can't deal with them. Here's a pruned version of a grep through /var/log, though, with all duplicate lines removed (there were about 40,000 of them!); note that because of the duplicate removal, they all show up as being in `user.log', but in fact there were also identical messages in `/var/log/messages', etc:
Attachment:
uo
Description: Log messages from hosted gconf
> > (2) Is Gnome's error recovery really this bad, or is something wrong > > with my setup? > > Even a journalling filesystem can't guarantee perfect recovery of > accidents. Of course not, but ext3 (and ext2 for that matter) tries _very_ hard, and suceeds about 99% of the time. From my admittedly naive reading of what happened to me, gconf didn't seem to do even the most basic attempts at recovering from the situation, or even give any useful advice to allow the user to do so (it didn't even give _cryptic_ advice, which would have been better than nothing). Any time there's a lock file, there's going to be situations where it accidentally gets left around, so a system like Gnome, which is aimed at naive users, absolutely needs to do some sort of error recovery. -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia