[ale] diagnosis
David Corbin
dcorbin at machturtle.com
Fri Apr 23 17:41:15 EDT 2004
I tried it with the "safe" version of top. It shows nothing that isn't in my
regular top. However, I did try "vmstat" which was there. It shows that the
free memory is disappear as the "buffers" is growing.
Does that help any?
On Monday 19 April 2004 20:35, James P. Kinney III wrote:
> I put up a page with the binaries and source on it :
>
> http://www.localnetsolutions.com/tools/
>
> Note: the procps page on sourceforge did not have an md5 checksum.
>
> On Mon, 2004-04-19 at 20:02, David Corbin wrote:
> > On Monday 19 April 2004 15:01, James P. Kinney III wrote:
> > > If it is a cracked machine, running a statically linked top from a CD
> > > will gain access to the real top data. Top is a common binary to fiddle
> > > with with a root kit.
> >
> > Sounds reasonable. Can you point me at such, or if not that, anybody got
> > any idea where the source to top is and I'll build my own.
> >
> > > It is certainly possible to _add_ a module or _remove_ a module, but
> > > change out the kernel with out a reboot (unless 2-kernel-monte is
> > > available, I have not been able to find this :( ). So the actual data
> > > stream for top is not tamper-able easily. Thus a known good
> > > statically-linked top would give access to the running system and show
> > > the _real_ processes that are running.
> > >
> > > If top shows no malicious files, it's time to take some snapshots over
> > > time to plot which app is failing.
> > >
> > > #!/bin/sh
> > > echo date >> /tmp/top.txt
> > > top -b -n 1 -c >> /tmp/top.txt
> > > echo "###############" >>/tmp/top.txt
> > > echo >>/tmp/top.txt
> > > echo >>/tmp/top.txt
> > >
> > > Run as a cron every minute for an hour.
> > >
> > > If you want, you can now mash/mangle the data into a nice plot using
> > > some perl and gnplot (or a spreadsheet).
> > >
> > > On Mon, 2004-04-19 at 11:56, Geoffrey wrote:
> > > > Dow Hurst wrote:
> > > > > How can we find the process that is soaking the memory? How do you
> > > > > manipulate /proc to find out the originating process that owns the
> > > > > memory being used? I know IRIX had tools to look at memory and see
> > > > > which processes owned what part of memory. Does Linux?
> > > > >
> > > > > Seems if you knew what was leaking you would have a major part of
> > > > > the battle won.
> > > >
> > > > I believe we mentioned top, but he noted that doesn't give him
> > > > anything. That's what concerns me. If it doesn't show, is it being
> > > > hidden for a reason???
More information about the Ale
mailing list