Jeremy Chadwick wrote: > Once the machine is hung like described, since running shell > commands (date/vmstat/even spawning sh itself) involves disk I/O, > this won't work. If date and vmstat could be cached in memory > somewhere, this might work, but I don't know how one would do that. > (A memory filesystem could work, but pretty much all of / would > have to be there for this to work...) > > The best I could do would be to have a cronjob or a process running > in a screen session which does date && vmstat -i over and over to a > log file, and examine that log once the machine hung like described. > This wouldn't tell us if the numbers were increasing/fluxuating > *after* the hang, though. :-( >
You *could* create a small ramdisk, copy /lib into it (along with /usr/bin/vmstat, /bin/sh, and any other needed utils), then set the LD_LIBRARAY_PATH to /mnt/lib or wherever the ramdisk is mounted and run vmstat. If you are already logged-in prior to the hang then utils on the mfs should run provided all their libraries are also on the mfs. I use a very similar process on a small Soekris box when I do an in-place flash upgrade which runs dd over the entire disk (a 32 MB compact flash card) while the box is still running from the same disk. My pre-upgrade script copies /sbin/reboot, /bin/dd, /lib/libc.so.6, and /lib/libutil.so.5 to a small mfs mounted at /mnt and sets LD_LIBRARY_PATH to /mnt prior to running dd (after which "reboot -lnq" is run, also from the mfs). -Proto _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
