Alex wrote:
>
> I'm not sure exactly what ate-up that extra gig of HD space, but a
> reboot fixed it. I'd rather have held off to find the cause, but I
> needed the server working quickly.

It's quite possible that something was filling up /tmp. Many distros
are configured to clear /tmp at reboot. Keep an eye on that for next time.

Melissa Danforth wrote:

> In alt.os.linux.slackware Alex <samalex@gmail.com> wrote:
> : I'm not sure exactly what ate-up that extra gig of HD space, but a
> : reboot fixed it. I'd rather have held off to find the cause, but I
> : needed the server working quickly.
>
> Since a reboot fixed it, this does point to something filling up /tmp,
> which should be emptied on reboot. In the future, make sure to record
> the output of ps and of top (top will spike a process up to the top of
> the list if it's doing excessive I/O, ps might not show this). Also
> look at the contents of /tmp as already posted. Another handy tool is
> the fuser command. This will show you all processes accessing a given
> partition at the moment.

If it was /tmp, du would have showed that. Besides, slackware doesn't clean
up /tmp on bootup.

To the op:

most likely something was writing to a file. you removed the file, and you
didn't kill the process. in that case, the file gets unlinked, but the
space will be unavailable until that process dies.

Alex wrote:
> Any ideas? In my hunt for some large log file or something, I ran this
> to find any files over 1 Meg in size, but nothing it spit out was a log
> file nor anything out of the ordinary:
> find -name '*' -size +1024k
>
> So any ideas what this could be? This box is behind a firewall and
> there's no way to get to it from the Internet, so I know it hasn't been
> hacked. Also it's the only Linux box on our network, and with me being
> the only person who uses Linux I know someone else hasn't screwed with
> the box.
>
> Thanks for any suggestions or ideas on what to check. It's running
> Slackware 10.2.

Try this as root:
cd /
find . -maxdepth 1 -type d -exec du -B 1024k -s {} \; | sort -nr | less

This shows you the directories that have the most data at the top (data use
listed in MB). Once you've found a big directory, change into, re-run the
"find" command earlier, and keep going until you find the directory that is
causing you grief.

Not an exact answer, but welcome to system administration

HTH,

James
--
Isn't it strange that the same people that laugh at gypsy fortune
tellers take economists seriously?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

_.-In alt.os.linux.slackware, Alex wrote the following -._
> I have two partitions, / (root) and /home. When I try to put something
> on / it says I'm out of space, which a df does show:
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/hda1 2847752 2847752 0 100% /
> /dev/hda2 3703644 260576 3251896 8% /home

I have noticed this too. As you and others have noted something was
filling up /tmp. I tracked it that far because I have temp as a
partition of its own. I was never able to figure out what was filling
tempt up though. du reported the size of tmp as being far larger than
the sum of the files and directories in it. No matter how hard I
looked in temp I couldn't find any hidden files or anything else that
could justify a gig of /tmp being used. Eventually I threw /tmp on a
larger partition and haven't worried about it since.

If I had to name a probram that was causing it then it would be one of
the following:
Xorg
fluxbox
elinks
slrn
firefox
uudeview

Those are the only massive memory hogs I have and ones like uudeview
don't even write to tmp so can be taken off the list.

- --
.-')) fauxascii.com ('-. | It's a damn poor mind that
' ..- .:" ) ( ":. -.. ' | can only think of one way to
((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFEI1IoSJec2PH9pbURAv5ZAJ9uxOkkjMN7Pk0VIZGTZO aI3kNG2QCfQU8+
fb9H7bLCEzjJLXVTr2OA2+w=
=uXut
-----END PGP SIGNATURE-----

On 2006-03-24, Faux_Pseudo <Faux.Pseudo@gmail.com> wrote:
>
> If I had to name a probram that was causing it then it would be one of
> the following:
> Xorg
> fluxbox
> elinks
> slrn
> firefox
> uudeview

If you use mc on occassion, as I do, you can put mc on that list. Just
checked tmp, 200 files from mc in the last two days.

Never noticed a problem with slrn or firefox

ken

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

_.-In alt.os.linux.slackware, No_One wrote the following -._
> If you use mc on occassion, as I do, you can put mc on that list. Just
> checked tmp, 200 files from mc in the last two days.
>
> Never noticed a problem with slrn or firefox

I haven't used mc since my early days (it helped me through the first
few weeks of *nix since it was like Xtree back on my old 286).

I have seen my slrn creep up to the 30m range when dealing with a few
thousand binary posts, and firefox has no problem going up past 147m.
I had to restart it yesturday so it is only at 81m right now. X is at
172m as I type this.

Oh and centericq when being used as an RSS app used to pull over
256m. I had to stop using that for RSS.

- --
.-')) fauxascii.com ('-. | It's a damn poor mind that
' ..- .:" ) ( ":. -.. ' | can only think of one way to
((,,_;'.;' UIN=66618055 ';. ';_,,)) | spell a word.
((_.YIM=Faux_Pseudo :._)) | - Andrew Jackson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFEI2JGSJec2PH9pbURAvUxAJ0bzJXchomoSmDnaadys1 pl+3zMiQCeIF8d
UQ0Q+0rpZEKLvyEMnUdRMg8=
=x7UR
-----END PGP SIGNATURE-----

In alt.os.linux.slackware Dominik L. Borkowski <dom@vbi.vt.edu> wrote:
: If it was /tmp, du would have showed that. Besides, slackware doesn't clean
: up /tmp on bootup.

Actually it does clean up certain portions of /tmp on reboot (grep the rc
scripts). If the problem lay within one of those files, it would have been
cleaned up on reboot.

: To the op:

: most likely something was writing to a file. you removed the file, and you
: didn't kill the process. in that case, the file gets unlinked, but the
: space will be unavailable until that process dies.

This is another possibility, which the fuser command would have helped
him track down.

Faux_Pseudo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> _.-In alt.os.linux.slackware, Alex wrote the following -._
>> I have two partitions, / (root) and /home. When I try to put something
>> on / it says I'm out of space, which a df does show:
>>
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> /dev/hda1 2847752 2847752 0 100% /
>> /dev/hda2 3703644 260576 3251896 8% /home
>
> I have noticed this too. As you and others have noted something was

Weird, I just checked my /tmp and found out kde had taken up 1.3GBytes of
space so I cleaned it out but I have no leak per se.

> firefox

I can't seem to find firefox writing much to my /tmp lsof shows just approx
8KB in /tmp/orbit-richard/ being opened? Most of the data is in my home
directory under ~/.mozilla 30Mbytes worth.

Richard

Faux_Pseudo <Faux.Pseudo@gmail.com> trolled:
> _.-In alt.os.linux.slackware, No_One wrote the following -._

> > If you use mc on occassion, as I do, you can put mc on that
> > list. Just checked tmp, 200 files from mc in the last two days.

> > Never noticed a problem with slrn or firefox

> I haven't used mc since my early days (it helped me through the first

And why did you share this with us? Anybody who uses the CLI and
who doesn't use mc is a fucking idiot. Oh, but we already knew
that. We saw your .sig.

Please, just stop posting.

cordially, as always,

rm

In alt.os.linux.slackware Melissa Danforth <danforth@pc60.cs.ucdavis.edu> wrote:
> In alt.os.linux.slackware Alex <samalex@gmail.com> wrote:
> : I'm not sure exactly what ate-up that extra gig of HD space, but a
> : reboot fixed it. I'd rather have held off to find the cause, but I
> : needed the server working quickly.
>
> Since a reboot fixed it, this does point to something filling up /tmp,
> which should be emptied on reboot. In the future, make sure to record

Another possibility is a open, but already deleted, logfile.
As long as the process is still active the file will still be there,
taking up space, but you will not be able to see it in ANY directory,
as it already has been removed there (it is currently just a i-node
with one active link, to the running process).
As a reboot kills the process, the file will now finally get removed.
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************