File system full

2004-04-05 Thread Paul Khavkine


Hi folks.


Today for i have noticed that the /tmp partition on one of our mail
servers was reported as
full. I have checked if there's any files in /tmp but found that it
wasn't true.


du reports that /tmp is only using 50K.

After a few minutes the size changed from 100% to 66%.

Even that makes no sense:

%df -h
..
/dev/amrd0s1f   492M   298M   155M66%/tmp

%du -skh /tmp/
 16K/tmp/


Any clues to why it behaves that way ?



Thanx
Paul


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: File system full

2004-04-05 Thread Mark
Paul Khavkine wrote:

 Today for i have noticed that the /tmp partition on one of our mail
 servers was reported as
 full. I have checked if there's any files in /tmp but found that it
 wasn't true.


 du reports that /tmp is only using 50K.

 After a few minutes the size changed from 100% to 66%.

 Even that makes no sense:

That would probably be the 'softupdates' effect. It was full, then whatever
filled it got deleted; and, due to the softupdates delay, you see it
gradually be freed again.

- Mark

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: File system full

2004-04-05 Thread Paul Khavkine


Well it did go down to 63% now but the partition is COMPLETELY empty, 16K
used.
Even 63% doesn't make sense.

How long for softupdates to flush all deleted data usually ?

The box is 4.6-STABLE BTW.


Thanx
Paul

Mark wrote:

 Paul Khavkine wrote:

  Today for i have noticed that the /tmp partition on one of our mail
  servers was reported as
  full. I have checked if there's any files in /tmp but found that it
  wasn't true.
 
 
  du reports that /tmp is only using 50K.
 
  After a few minutes the size changed from 100% to 66%.
 
  Even that makes no sense:

 That would probably be the 'softupdates' effect. It was full, then whatever
 filled it got deleted; and, due to the softupdates delay, you see it
 gradually be freed again.

 - Mark

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: File system full

2004-04-05 Thread Clifton Royston
On Mon, Apr 05, 2004 at 12:00:53PM -0700, [EMAIL PROTECTED] wrote:
 Date: Mon, 05 Apr 2004 14:49:42 -0400
 From: Paul Khavkine [EMAIL PROTECTED]
 Subject: File system full
 To: [EMAIL PROTECTED]
...
 
 Today for i have noticed that the /tmp partition on one of our mail
 servers was reported as
 full. I have checked if there's any files in /tmp but found that it
 wasn't true.
 
 du reports that /tmp is only using 50K.
 
 After a few minutes the size changed from 100% to 66%.
 
 Even that makes no sense:
 
 %df -h
 ..
 /dev/amrd0s1f   492M   298M   155M66%/tmp
 
 %du -skh /tmp/
  16K/tmp/
 
 
 Any clues to why it behaves that way ?

  Almost certainly a classic all-Un*x problem:

  There are long-lived running processes holding already-deleted files
open in /tmp.  Such files have already removed from the directories,
and hence are not visible to ls or du, but can not be freed by the
operating system until the process which opened them terminates, hence
their space shows up in df and is not free for allocation.  This can be
a form of local DOS, but it's more likely a coding/design error.

  I've particularly run into this with Apache + mod_perl on a high-load
website.  Apache keeps processes around for a relatively long time, and
in the persistent perl environment, if files are not explicitly closed
they remain open by the interpreter - so a Perl script which creates
temp files and doesn't explicitly close them at the end of each
execution pass can really rack up the disk space with invisible
files.

  -- Clifton

-- 
  Clifton Royston  --  [EMAIL PROTECTED] 
 Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
  Did you ever milk this kind of cow?  Well we can do it.  We know how.
If you never did, you should.  These things are fun, and fun is good.
 -- Dr. Seuss
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: File system full

2004-04-05 Thread Paul Khavkine

I see.

Any way to find out what process is doing it ?

I doubt it's a local DoS since noone has shell access to the machine.


Thanx
Paul


Clifton Royston wrote:

 On Mon, Apr 05, 2004 at 12:00:53PM -0700, [EMAIL PROTECTED] wrote:
  Date: Mon, 05 Apr 2004 14:49:42 -0400
  From: Paul Khavkine [EMAIL PROTECTED]
  Subject: File system full
  To: [EMAIL PROTECTED]
 ...
 
  Today for i have noticed that the /tmp partition on one of our mail
  servers was reported as
  full. I have checked if there's any files in /tmp but found that it
  wasn't true.
 
  du reports that /tmp is only using 50K.
 
  After a few minutes the size changed from 100% to 66%.
 
  Even that makes no sense:
 
  %df -h
  ..
  /dev/amrd0s1f   492M   298M   155M66%/tmp
 
  %du -skh /tmp/
   16K/tmp/
 
 
  Any clues to why it behaves that way ?

   Almost certainly a classic all-Un*x problem:

   There are long-lived running processes holding already-deleted files
 open in /tmp.  Such files have already removed from the directories,
 and hence are not visible to ls or du, but can not be freed by the
 operating system until the process which opened them terminates, hence
 their space shows up in df and is not free for allocation.  This can be
 a form of local DOS, but it's more likely a coding/design error.

   I've particularly run into this with Apache + mod_perl on a high-load
 website.  Apache keeps processes around for a relatively long time, and
 in the persistent perl environment, if files are not explicitly closed
 they remain open by the interpreter - so a Perl script which creates
 temp files and doesn't explicitly close them at the end of each
 execution pass can really rack up the disk space with invisible
 files.

   -- Clifton

 --
   Clifton Royston  --  [EMAIL PROTECTED]
  Tiki Technologies Lead Programmer/Software Architect
 Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
   Did you ever milk this kind of cow?  Well we can do it.  We know how.
 If you never did, you should.  These things are fun, and fun is good.
  -- Dr. Seuss

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: File system full

2004-04-05 Thread Clifton Royston
On Mon, Apr 05, 2004 at 03:13:54PM -0400, Paul Khavkine wrote:
 I see.
 
 Any way to find out what process is doing it ?
 
 I doubt it's a local DoS since noone has shell access to the machine.
 
 Thanx
 Paul

  You should be able to use fstat (or lsof, if you have it installed)
to find what files are currently open by running processes, and look
through the output for files in /tmp.

  man fstat, and look at the -f option.

  -- Clifton

-- 
  Clifton Royston  --  [EMAIL PROTECTED] 
 Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
  Did you ever milk this kind of cow?  Well we can do it.  We know how.
If you never did, you should.  These things are fun, and fun is good.
 -- Dr. Seuss
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: file system full

1999-10-09 Thread Dan Moschuk


| Too many open file descriptors.  This has nothing to do with
|  the file system.
| 
| Is there anyway this can be gotten around?  A friend has a mail server
| that will spontaneously do this then crash.
| 
| Jamie

If you're csh'ish, you can use the ``limit'' command to see what your allowed
openfiles are.  You can raise this with ``unlimit''.

You will also want to look at a few kernel options if the above doesn't fix
it.  

-- 
Dan Moschuk ([EMAIL PROTECTED])
"Try not.  Do, or do not.  There is no try."
-- Yoda


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: file system full

1999-10-09 Thread Kip Macy

Assuming its descriptor usage is bounded, i.e. it is not leaking
descriptors, you can solve the problem by using sysctl to raise the max
files and max files per process.

-Kip

On Sat, 9 Oct 1999, James Howard wrote:

 On Fri, 8 Oct 1999, Chris Costello wrote:
 
 Too many open file descriptors.  This has nothing to do with
  the file system.
 
 Is there anyway this can be gotten around?  A friend has a mail server
 that will spontaneously do this then crash.
 
 Jamie
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-hackers" in the body of the message
 
 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: file system full

1999-10-08 Thread Chris Costello

On Fri, Oct 08, 1999, James Howard wrote:
 When running "strobe" (from the ports collection, it is a port scanner), I
 often or always get the message "file: table is full" many, many times.
 I have seen this under 2.2.6 through 4.0.  What exactly is going wrong
 here and what should I do to fix it?

   Too many open file descriptors.  This has nothing to do with
the file system.

-- 
|Chris Costello [EMAIL PROTECTED]
|Never lick a gift horse in the mouth.
`-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: file system full

1999-10-08 Thread James Howard

On Fri, 8 Oct 1999, Chris Costello wrote:

Too many open file descriptors.  This has nothing to do with
 the file system.

Is there anyway this can be gotten around?  A friend has a mail server
that will spontaneously do this then crash.

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message