[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- <!--x-content-type: text/plain -->
- <!--x-date: Sat Apr 24 16:04:22 2004 -->
- <!--x-from-r13: wxvaarl ng ybpnyargfbyhgvbaf.pbz (Xnzrf B. Yvaarl WWW) -->
- <!--x-message-id: [email protected] -->
- <!--x-reference: [email protected] -->
- <!--x-reference: [email protected] -->
- <!--x-reference: [email protected] -->
- <!--x-reference: [email protected] --> "http://www.w3.org/TR/html4/loose.dtd">
- <!--x-subject: [ale] diagnosis -->
- <li><em>date</em>: Sat Apr 24 16:04:22 2004</li>
- <li><em>from</em>: jkinney at localnetsolutions.com (James P. Kinney III)</li>
- <li><em>in-reply-to</em>: <<a href="msg01060.html">[email protected]</a>></li>
- <li><em>references</em>: <<a href="msg00645.html">[email protected]</a>> <<a href="msg01037.html">[email protected]</a>> <<a href="msg01047.html">[email protected]</a>> <<a href="msg01060.html">[email protected]</a>></li>
- <li><em>subject</em>: [ale] diagnosis</li>
Well, utmp is a storage area for logins and usage info. It that file is
growing in single user mode with nothing else running, you have a
problem. The kernel should be what is generating the data for the utmp
file. Since the presence of utmp initiates the memory loss, I would
suspect that kernel is corrupted and is not flushing the write to utmp
and is instead buffering the write process and/or data. This may
indicate a bad hard drive, trojaned kernel or failing RAM.
Run memtest and rule out that. Then copy a kernel from a CD distribution
and set lilo/grub to use that kernel. Then boot to single user, touch
utmp, reboot back to single user with the same CD kernel and watch the
top process. If there is still the problem, drop in an other hard drive,
make it the /var partition, and try again.
If all that fails, get a Geiger counter and start looking for a
radiation source that can cause bit flips :)
>
> > 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 :
> > > >
> > > > <a rel="nofollow" href="http://www.localnetsolutions.com/tools/";>http://www.localnetsolutions.com/tools/</a>
> > > >
> > > > 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
> > > <a rel="nofollow" href="http://www.ale.org/mailman/listinfo/ale";>http://www.ale.org/mailman/listinfo/ale</a>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> <a rel="nofollow" href="http://www.ale.org/mailman/listinfo/ale";>http://www.ale.org/mailman/listinfo/ale</a>
--
James P. Kinney III \Changing the mobile computing world/
CEO & Director of Engineering \ one Linux user /
Local Net Solutions,LLC \ at a time. /
770-493-8244 \.___________________________./
<a rel="nofollow" href="http://www.localnetsolutions.com";>http://www.localnetsolutions.com</a>
GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<ul><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><a name="01105" href="msg01105.html">[ale] diagnosis</a></strong>
<ul><li><em>From:</em> dcorbin at machturtle.com (David Corbin)</li></ul></li>
</ul></li></ul>
<!--X-Follow-Ups-End-->
<!--X-References-->
<ul><li><strong>References</strong>:
<ul>
<li><strong><a name="00645" href="msg00645.html">[ale] diagnosis</a></strong>
<ul><li><em>From:</em> dcorbin at machturtle.com (David Corbin)</li></ul></li>
<li><strong><a name="01037" href="msg01037.html">[ale] diagnosis</a></strong>
<ul><li><em>From:</em> dcorbin at machturtle.com (David Corbin)</li></ul></li>
<li><strong><a name="01047" href="msg01047.html">[ale] diagnosis</a></strong>
<ul><li><em>From:</em> jkinney at localnetsolutions.com (James P. Kinney III)</li></ul></li>
<li><strong><a name="01060" href="msg01060.html">[ale] diagnosis</a></strong>
<ul><li><em>From:</em> dcorbin at machturtle.com (David Corbin)</li></ul></li>
</ul></li></ul>
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg01070.html">[ale] QoS Question</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg01072.html">[ale] diagnosis</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg01060.html">[ale] diagnosis</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg01105.html">[ale] diagnosis</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#01071"><strong>Date</strong></a></li>
<li><a href="threads.html#01071"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>