Jon Dowland wrote:
lets just say, that it's a moderately loaded virtual machine, running on
top of a RAIDed, LVM, DRBD disk stack - a task that sucks up huge
amounts of disk i/o is to be avoided.
On 15/06/2010 15:49, Miles Fidelman wrote:
For educational purposes only:
That's just a silly suggestion, beyond the obvious of searching for
files named deb_checkmd5sum, of which there are none - doing a full
text search on a terabyte of files is just too resource intensive.
I don't think it is silly. The volume of files in storage terms is not
relevant; the number of files/directories (the complexity of the
filesystem) is the issue which will impact how long the job takes to
run. You can de-prioritise it below important tasks if you are concerned
Before attempting this, though, you can search for files inside packages
via http://packages.debian.org/. That is enough to prove that there are
no official packages containing a filename ending in deb_checkmd5sum.
done, as well as dpkg -L - both of which come up with no results
for that matter, googling both deb_checkmd5sum and checkmd5sum - returns
very slim pickings - a pretty sure sign that this is a specialized
process buried in a specialized program or library
as indicated below, the only way I found it was by digging deep into
config files and code
In any case, it turns out to be a procedure call inside Tiger - a
somewhat aging security audit package. Turns out that Tiger runs an
hourly cron job that, in turn, calls its own routine that parcels out
tasks across different hours in the day. Buried way deep in nested
config files (cron -> run.hourly -> tigercron) is a job that runs at
1am that invokes a Tiger sub-package called "check_system" - which in
turns runs a procedure called "checkmd5sum" - which shows up in a
process listing as deb_checkmd5sum (which, I think, comes from a
library). We'll see if turning off that job stops the nightly crashes.
Interesting. I'd never heard of "tiger", but I see that it is packaged:
I really can't believe there aren't better crash logging facilities
No need to disbelieve, there undoubtably are - we haven't even
established what you mean by "crash" on debian-user yet.
crash = one minute the machine is running, the next it's rebooting itself
it's a simple question, that I've asked several ways with no answer:
- what's the Linux equivalent to BSD/Solaris savecore? (automatically
save a core image between kernel panic and reboot)
- is there something more modern than lkcd or kexec/kdump?
- is kexec/kdump configured in the standard Lenny kernel (and
particularly the xen varient of the kernel)
--- if not, is there a good tool for capturing pre-crash system state
that doesn't involve building a custom kernel?
luckily, despite not getting any answer, it looks like simply running
"top" in a window, and seeing what was running when the machine died led
me to deb_checkmd5sum
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra