> Hi,
>
> We are building an embedded system using the Redhat 4.2 release. There
> is no console
> ...
> will have, typically, no power outages. However, the processor card may
> be extracted from the card cage, killing the system without warning.
I think, it would be a good idea, to add a mechanical lock for the card.
Before you could remove it, you'd have to unlock it, which your system
can notice and sync and remount the disk read-only (this takes you a
couple of milliseconds) or even do a proper shutdown (which could be done
in a few seconds).
> The system files are installed on a flash device, and the majority of
> the data files are read-only. So far, the only file system errors
> resulting from improper shutdown have
> been on the partition where system logs are stored.
>
> Is there any way to completely disable the system logs?
See man 8 syslogd: you can redirect the log whereever you want by just
fiddling with the /etc/syslog.conf file. Also read the klogd manpage ...
> Is there any way to log to ramdisk, so that corruption does not exist on
> restart?
Very easily: Don't mount the var/log directory from a harddisk but from a
ramdisk. Try dd if=/dev/zero of=/dev/ram0 bs=1024 size=256 to create a
256kB ramdisk. mkfs.minix /dev/ram0 will create a minix filesystem on it
(you could use ext2fs, too, but for very small FS, minix is better,
because it needs less space for managment). mount it: mount /dev/ram0
/var/log. Of course you need the kernel to be compiled with ramdisk
support. (Let the kerneld load the modules or add it by hand: modprobe rd;
modprobe minix) Of course, this should be added to your system setup
scripts ...
Use cron scripts to transfer the logs to harddisk once every
hour to avoid the ramdisk to become filled up: remount harddisk rw, mv
/var/log/LOGFILE /mounted/partition/LOGFILE-`date +%y%m%d-%H:%M`, remount
ro, killall -1 syslogd to signal it to close syslog file and to reopen it.
You can use a monthly cron script to remove old syslog files from disk.
If you're absolutley not interested in the syslog files, you could easily
remove them and signal syslogd, but then it's easier not to log at all.
(I don't recommend this, because it 'll be hard to do error detection
without syslogs.)
The solution has one disadvantage: It eats some RAM and there's still the
chance (approx 1/3600), that the processor is removed while the syslog is
transfered to disk.
> Better yet, is there some recovery scheme that does not require console
> intervention?
> (apparently the file system check will not run unattended)
e2fsck -p won't ask you questions unless it doesn't know what to do ...
Kurt Garloff, Dortmund
<K.Garloff@ping.de>
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu