Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got a tmp-folder with 14 million php session files in my home directory. At least that's what I think it is, it's not like I could ls it or anything.

I've tried using find with the -exec rm {} \; commands but that didn't work. ls 'sess_0*' | xargs rm did neither.

I'm currently running rm -rf tmp but after two hours the folder appears to be the same size.

How can I empty this folder?

Does anyone have a clue what caused it in the beginning? I don't remember changing anything critical lately.


REFERENCE INFO:

I suddenly encountered an error where SESSIONS could no longer be written to disk:

[Mon Apr 19 19:58:32 2010] [warn] mod_fcgid: stderr: PHP Warning: Unknown: open(/var/www/clients/client1/web1/tmp/sess_8e12742b62aa68a3f9476ec80222bbfb, O_RDWR) failed: No space left on device (28) in Unknown on line 0

[Mon Apr 19 19:58:32 2010] [warn] mod_fcgid: stderr: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/www/clients/client1/web1/tmp) in Unknown on line 0

I ran:

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              457G  126G  308G  29% /
tmpfs                 1.8G     0  1.8G   0% /lib/init/rw
udev                   10M  664K  9.4M   7% /dev
tmpfs                 1.8G     0  1.8G   0% /dev/shm

But as you can see, the disk isn't full.

So I had a look in the syslog which says the following 20 times per second:

kernel: [19570794.361241] EXT3-fs warning (device md0): ext3_dx_add_entry: Directory index full!

This led me thinking to a full folder, obviously, but since my web folder only has 60k files (having counted them), I guessed it was the tmp folder (the local one, for this instance of php) that messed things up.

Some commands I ran:

$ sudo ls sess_a* | xargs rm -f bash: /usr/bin/sudo: Argument list too long

find . -exec rm {} \; rm: cannot remove directory '.' find: cannot fork: Cannot allocate memory

I'm running Debian Lenny, php5, ISPConfig, SuEXEC and Fast-CGI.

share|improve this question
    
See serverfault.com/questions/129843/… –  voretaq7 Apr 19 '10 at 18:25
    
In the short term you could try renaming the full tmp directory and creating a new one in its place. This may allow your system to start working again while you work on deleting the junk out of that directory. –  Zoredache Apr 19 '10 at 19:37
    
Yeah, that's what I'm doing, I've moved the tmp folder and the rm -rf is eating, but very slowly. It's taken the whole night to prune 500k files, so there's lots more to go. :-) –  Jonatan Littke Apr 20 '10 at 6:32
    
When you say "the disk isn't full", you're thinking of "space" for storage. But you're out of inodes, that's why it can't create any more files, so in a way, the filesystem is indeed full. –  MattBianco Aug 3 '12 at 12:07
add comment

3 Answers 3

find /tmp -name "sess_*" -exec rm {} \;

share|improve this answer
    
As I said, I've already tried that. I tried sess_0* which is supposed to be an even smaller subset than the one you mentioned, and that didn't work. Also a small note, it isn't the global /tmp (in which case a simple reboot would've remounted tmpfs and cleared the folder). –  Jonatan Littke Apr 19 '10 at 18:17
    
you said ls 'sess_0*' | xargs rm, which fills up ls buffer and bombs. This find command works flawlessly for me when i have to delete hundreds of thousands of amavis/spamassassin quarantine files... –  solefald Apr 19 '10 at 18:29
    
You're right. But do remember I did run another find which failed. But perhaps that was because the amount of files were too large? I thought -exec would execute as each file was read, not after they'd all been ran through once. –  Jonatan Littke Apr 19 '10 at 19:02
add comment

I'm using this method to delete 2.3 million - looks like it will be finished in about 10-15 minutes

http://www.binarysludge.com/2012/01/01/how-to-delete-millions-of-files-linux/

share|improve this answer
    
Answers that just consist of links to some other page are not generally considered good answers as they cease to be useful if the link ever dies. Please consider expanding your answer to contain enough detail to stand on its own without the external reference. Thanks! –  Scott Pack Sep 27 '12 at 3:52
add comment

First of all, the errors about not being able to write to

/var/www/clients/client1/web1/tmp/

doesn't mean that it is this directory that has all the files, just that it is there it's trying to write when it logs the error. But you have located the files, and are about to remove them.

  • stop the web server (if possible) to prevent creation of more, and stop spewing error messages
  • clean up
  • restart web server
  • observe if it starts again

For the cleanup step, assuming the files to clean are in /var/www/clients/client1/web1/tmp, first become the same effective user as the one creating the session files (probably one of apache or httpd or www-data), then:

  • cd /var/www/clients/client1/web1/tmp
  • ls -f | grep ^sess_ | xargs rm -f
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.