Hi Bob, You are probably correct about file system corruption. I found a large number of the following type of errors:
/var/log/messages.3:Jun 23 23:14:49 localhost kernel: EXT3-fs error (device dm-0): ext3_free_blocks: Freeing blocks not in datazone - block = 1315991916, count = 1 /var/log/messages.3:Jun 23 23:14:49 localhost kernel: EXT3-fs error (device dm-0): ext3_free_blocks_sb: bit already cleared for block 647337 I had not rebooted for a long time, so the corrupted files were not detected until long after the errors occurred. Again, thanks, Reg. On Tue, July 17, 2007 4:09 pm, Bob Proulx wrote: > Reg. Charney wrote: > >> The result of this command is: >> >> >> [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log >> drwx------ 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg -rw------- 1 reg >> reg 0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log -rw------- >> 1 reg reg 0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-SQil1b.log >> > > Of course now with new files those look fine. :-( > > >> The exact command that raised the segmentation fault was: >> rm -rf /tmp/kde-* Thus, the error may have been in the glob expansion, >> not in the rm command. > > You might want to scan through your system logs and see if any > filesystem errors are logged there. It appears that you were having some > filesystem related issues and perhaps there will be a clue left behind > about it there. > > Segmentation violations are always bugs. The problem is determining > the root cause of the bug. Here it could be in the glob expansion or in > system added patches. Because the rm command is fairly simple I am in a > little bit of disbelief that the problem is there but it could be. > >> the following was the output I that I recall I received with the ls >> command: >> >> >> [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log >> drwx------ 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg ?--------- ? reg >> reg ? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-XYwuxw.log ?--------- >> ? reg reg ? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-STuxyz.log >> > > This appears to indicate that the stat calls from ls to the kernel > requesting filesystem information failed. The ls command reported the > information that it had available. for the fields that it did not have > information it reported a '?'. > > If the stat calls were failing then that would indicate a filesystem > problem and is why I think there may be errors logged to the system log > file usually /var/log/syslog or /var/log/messages or some such system > dependent location. > >> Again, the ls command at the time could not tell me this. >> > > Oh well. > > >>>> Because the type of these crash files are unknown, the rm command >>>> fails with a segment fault on my Intel IA86 machine (a MacBook >>>> running Parallels Fedora Core 6 Linux under Mac OS X (10.4)). >>>> >>> >>> It would be good if you could show us the exact output. >>> >> >> I wish I could show this now, but the system was not in a state then >> that I could do this. >> > > The reason I said that was because saying "the type of the files are > unknown" did not make sense to me since unix-like filesystems do not have > file types (in the same way that older filesystems had file types). At > that point I was stuck. But now with the additional information about the > ls listing we now know that there were failures reported by the filesystem > in response to the stat kernel filesystem calls. That is obviously not > good. But it probably not a bug in coreutils, which is good for us on the > coreutils list but worse for you. > > About all of the advice I can offer is to keep an eye on the > filesystem and see if the problem returns. If the problem does return then > try running 'strace' and saving the output. > > strace -o /tmp/strace.out ls -ld /path/to/file > > The strace will show the system calls and return values. If stat > calls are failing this should show the information for those failures. > > Good luck! > > > Bob > > > _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
