I asked:
I deleted a vital log file. The file remains
open by an application. Is there a way to find
the inode and rebuild a link to it?
-= -= -= -= -= -=
Thanks to all who answered (listed below), two
details includeed. A few asked for the summary.
The answer is, you can _try_ with fsck.
Shutdown sensitive processes (database, etc).
If possible, find inode of file (lsof; pfiles).
Crash the system, boot to single user mode.
Run fsck on the affected file system.
The lost+found directory will have a file by
the number of the inode. This should be the lost
file. Two detailed descriptions are at the end.
I have not tried this yet, I just wrote off
the missing few hours of the log, and restarted
the process that was still using it.
I may try it during the next scheduled reboot.
Thanks to:
Michael Maciolek <mikem@centerline.com> -see below
Kevin Sheehan <Kevin.Sheehan@uniq.com.au> "
and to:
boenning <boenning@capcom.de>
"Joe Morel" <joe_morel@corp.disney.com>
"Rodney C. Marable" <marable@firefly.net>
Harvey Wamboldt <harvey@iotek.ns.ca>
Stefan Voss <s.voss@terradata.de>
Birger Wathne <birger@sdata.no>
Michael Maciolek <mikem@centerline.com> wrote:
I've got one move that may sound pretty scary, but unless you know
any filesystem gurus who can edit the raw disk image with fsdb, this
is probably your best bet. I've done this, once, and it's not for
the faint-hearted.
Basically, crash the machine and let 'fsck' reconnect the lost inode
for you. Here's a step-by-step:
If you don't have 'lsof' (list open files), get it, build it and use
it to figure out the inode number of your crucial file. Just do:
lsof -p pid
and look at the output. It should look something like this:
#lsof -p 22592
CMD PID FD TYPE DEVICE SIZE/OFF INODE NAME
sh 22592 cwd VDIR 115, 0 1536 2 /
(/dev/vx/dsk/rootvol)
sh 22592 txt VREG 115, 0 179432 169927 /
(/dev/vx/dsk/rootvol)
sh 22592 0u VCHR 24, 0 0x158e
/devices/pseudo/pts@0:0->pts
sh 22592 1u VCHR 24, 0 0x158e
/devices/pseudo/pts@0:0->pts
sh 22592 2u VCHR 24, 0 0x158e
/devices/pseudo/pts@0:0->pts
sh 22592 4u inet 0xfc8862d0 0x0 UDP *:43073
#
You don't absolutely *have* to have 'lsof', but it helps to pick out
the inode number of your critical file when it comes time to run 'fsck'
So now you're ready to proceed:
0. get everyone signed off, cleanly terminate all other critical
processes, and do general cleanup - everything you'd normally
do before a reboot. Just make sure that the crucial process,
the one that's holding the inode, continues to run!
1. sync [from a root prompt while machine is still up]
2. stop-A [RESIST THE URGE to type 'sync' at the OK prompt!!!]
3. power off
4. power on, Stop-A, boot -s
5. when the system comes up single-user, login as root. Run 'fsck'
manually on the filesystem which contains your critical log file.
'fsck' will find an unreferenced inode or file.
DO NOT allow fsck to remove the unreferenced inode.
DO allow fsck to re-link it.
Allow fsck to complete its check of your filesystem, watching
the messages carefully for any attempts to remove unreferenced
inodes or files.
6. mount the filesystem by hand (if it's not already mounted) and
take a look in that filesystem's 'lost+found' directory. There
should be a file named, say, #12345 (if 12345 is the inode number
of your critical file) in that 'lost+found' directory. You can
move and rename that file to wherever it's supposed to be.
This is a little risky, because it involves crashing the machine,
under controlled circumstances. The risks are minimal because you
can safely 'sync' the machine just before you crash, but you might
want to take other precautions - kill any unrelated processes and
unmount any unrelated filesystems - but be *very* careful. The one
process that's holding that inode is absolutely crucial! If you
kill it by accident, Stop-A the machine immediately and you might
still have a chance if you pick up at step 3.
If you get a better answer, I'd love to see it!
regards,
Michael
Kevin Sheehan <Kevin.Sheehan@uniq.com.au> wrote:
1) issue the sync command
2) L1-A (STOP-A) the machine - do *NOT* halt it
3) on reboot/fsck it should be an unreferenced file and put in
lost+found
Step 2 is the dangerous one, but this is known to work for open files
that have been unlinked...
The other ways all involve either playing with the in-core and disk
inode and/or hand crafting a directory entry which is bit more brain
surgery.
l & h,
kev
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:35 CDT