Prev: telnetd in Squeeze; was new authentication mechanism in Squeeze?
Next: To force an app running in windowed mode rather than in full screen.
From: Huang, Tao on 15 Jun 2010 11:50
Since "deb_checkmd5sum" is a running process.
there's better way to locate it on your hard drive.
look into /proc/$PID/exe, which is a link to the full path of the
respective process.

in your case, deb_checkmd5sum caused the system to crash.
so it's possible that you don't have enough time to do this by hand.
write a script that runs just before the cron job to reveal the real
command invoked.

what's more, the file is also very likely to be located with a simple

$ mlocate/locate deb_checkmd5sum

and as mentioned by Jon, a de-prioritized

$ find / -name deb_checkmd5sum

doesn't take up much resource, either.
it dosn't hurt to use mlocate and find in the first place.


Regards,
Tao
--
Link: http://www.google.com/profiles/UniIsland



On Tue, Jun 15, 2010 at 10:49 PM, Miles Fidelman
<mfidelman(a)meetinghouse.net> 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.
>
> 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.
>
> I really can't believe there aren't better crash logging facilities for
> Debian.
>
> Huang, Tao wrote:
>>
>> Why not search for the process name in your hard drive?
>>
>> Tao
>> --
>> Link: http://www.google.com/profiles/UniIsland
>>
>>
>>
>> On Mon, Jun 14, 2010 at 7:52 PM, Miles Fidelman
>> <mfidelman(a)meetinghouse.net>  wrote:
>>
>>>
>>> Anybody recognize this process name?
>>>
>>> I'm seeing a nightly crash, and this seems to be running at the time
>>> (I've
>>> been leaving top running in a window - deb_checkmd5sum seems to be at the
>>> top of the list each time the machine crashes).
>>>
>>> I expect it's part of a nightly cron job, but I'm (not yet) sure which
>>> one.
>>>
>>> Thanks for any pointers.
>>>
>>> Miles Fidelman
>>>
>>> --
>>> In theory, there is no difference between theory and practice.
>>> In<fnord>    practice, there is.   .... Yogi Berra
>>>
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a
>>> subject
>>> of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
>>> Archive: http://lists.debian.org/4C1617F2.6050803(a)meetinghouse.net
>>>
>>>
>>>
>
>
> --
> In theory, there is no difference between theory and practice.
> In<fnord>  practice, there is.   .... Yogi Berra
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject
> of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
> Archive: http://lists.debian.org/4C1792FC.3010000(a)meetinghouse.net
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AANLkTil4cQYXcizbkLKKrnxhe87xV4A0fydjHXd0d4qa(a)mail.gmail.com
From: Miles Fidelman on 15 Jun 2010 12:30
Jon Dowland wrote:
> 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
> about impact.
>
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.
> 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:
> http://packages.qa.debian.org/t/tiger.html
>
and ancient
>> I really can't believe there aren't better crash logging facilities
>> for Debian.
>>
> 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

Miles Fidelman



--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra



--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C17A8F6.3000901(a)meetinghouse.net
First  |  Prev  | 
Pages: 1 2
Prev: telnetd in Squeeze; was new authentication mechanism in Squeeze?
Next: To force an app running in windowed mode rather than in full screen.