[ale] diagnosis

[Dow Hurst]

James,
This results in an eventual system crash, though.  But, you have great advice 
on eliminating as many processes as possible while still checking.

In fact, he could just use the startup/stop scripts to start one process at a 
time.  Redefine a new special runlevel, say 4, that is similar to 3, but 
without any of the usual extra stuff.  You could play with adding and 
subtracting processes until you isolated the problem.
Dow




James P. Kinney III wrote:
> Then stop worrying. The 2.4.18+ kernels have some rather aggressive
> memory caching. The buffers grow as the system is used to make data
> access faster on a reuse of old data. Some apps (mozilla) don't release
> buffer ram as fast as the chance of reuse is high. If the system needs
> more non-buffered ram, the buffers get dumped out to disk cache. Top is
> also a buffering hog. 
> 
> To really test the system for nefarious RAM usage, telinit S to drop to
> single user mode, then run the clean top. If that is OK, bump up to
> telinit 2, then 3 and finally 5. There is a host of stuff that runs with
> X that can be causing cache to grow over time while essentially "doing
> nothing". It really and "undocumented feature" of gnome, KDE, and X :)
> 
> On Fri, 2004-04-23 at 17:37, David Corbin wrote:
> 
>>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???
>>
>>_______________________________________________
>>Ale mailing list
>>Ale at ale.org
>>http://www.ale.org/mailman/listinfo/ale
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Ale mailing list
>>Ale at ale.org
>>http://www.ale.org/mailman/listinfo/ale

-- 
__________________________________________________________
Dow Hurst                  Office: 770-499-3428            *
Systems Support Specialist    Fax: 770-423-6744            *
1000 Chastain Rd. Bldg. 12                                 *
Chemistry Department SC428  Email:   dhurst at kennesaw.edu   *
Kennesaw State University         Dow.Hurst at mindspring.com *
Kennesaw, GA 30144                                         *
************************************************************
This message (including any attachments) contains          *
confidential information intended for a specific individual*
and purpose, and is protected by law.  If you are not the  *
intended recipient, you should delete this message and are *
hereby notified that any disclosure, copying, distribution *
of this message, or the taking of any action based on it,  *
is strictly prohibited.                                    *
************************************************************