Description of Problem: Description of your problem: SYSTEM:2.2.16-22smp kernel on Compaq ProLiant ML330 Single Pentium3 Problem: System eating memory. Always getting "too many open files error because file-max is set at 4096 and the High water mark is always at 4096 unless I reboot even though the fd's in use never goes over 200-300. Because of this we bumped max-files to 8196 and inode-max to 16384. That go ride of the open file errors, but the system crashed 12 hours later. I then upped the memory from .5gig to 1gig and rebooted. The system quickly chewed up the memory and crashed a day an a half later. Here is the output from vmstat. Notice the free mem diff between Friday and Monday. Is there a fix for this problem, and where is my memory going it doesn't even seem to know how much mem there is installed any more?? procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 779752 11380 48264 0 0 9 5 160 120 1 1 98 0 0 0 0 779752 11380 48264 0 0 0 4 136 67 0 2 98 0 0 0 0 779744 11384 48264 0 0 0 5 143 91 1 2 98 NOW::: procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 1944 5448 618356 135536 0 0 5 2 134 54 0 0 99 0 0 0 1944 5436 618360 135544 0 0 0 1 164 97 1 1 98 0 0 0 1944 5432 618364 135544 0 0 0 6 165 68 1 2 97 How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
Your free memory is getting used for cache; note the differences in cache settings. It's perfectly normal, and cache memory will be freed if it's needed for something else.
This is *not* resolved. The major problem remains. file-max is set at 4092, The system at some point uses all of this so column 1 and 3 are now 4092 and column 2(files open now is under 100 99% of the time). REDHAT is not giving back the file descriptors when it doesn't need them. When I bump file-max to 8194 and 3x that for inode-max, the system crashes within 12 hours and never takes more than 5713 of the 8194. I had to set file-max back to default because it keeps crashing. Doesn't happen at the default setting, but now I get continuous "Too many open files" and everything runs like crap. I have reproduce the crash 5 times in a row. I can't mess with this *production* server until I get a real answer at to why the file-max setting screws the system up and why it doesn't let go of fd's. also......memory still does not add up, but this is not the problem causing the crashing. free buff cache --- 4420 600672 158544 ---( cache included this does not equal on even come close to one gig.)
assigning to kernel. free + buffers + cache is missing the amount of memory actually in use.
1) What sort of applications are you running 2) Does this still happen with the 2.2.19 update kernel we released a few months ago
We are running apache_1.3.12 with about 30 virtual hosts. That is basically it though. It is our Primary Web server. We are running Redhat Kernel 2.2.16-22smp #1 SMP, I am not aware that 2.2.19 fixes this problem.
Although I'm not aware of any leaks in 2.2.16-22, it might be worth it to try 2.2.19 as released, as it has a much better VM subsystem.
Upgraded to 2.2.19 and still having the same problem when I double file-max settings.(system still not releasing the fds and then crashes.) When i do uname -r I still get 2.2.16-22smp. I rebooted and still see the same. Is that normal? The rpm installed without a problem. Below is my boot directory. I am not sure if it is correct or not some links still go to the old image. [root@petros /boot]# ls -lrt total 6024 -rw-r--r-- 1 root root 655177 Aug 22 2000 vmlinuz-2.2.16-22smp -rwxr-xr-x 1 root root 1743421 Aug 22 2000 vmlinux-2.2.16-22smp -rw-r--r-- 1 root root 11773 Aug 22 2000 module-info-2.2.16-22smp -rw-r--r-- 1 root root 213234 Aug 22 2000 System.map-2.2.16-22smp -rw-r--r-- 1 root root 640 Aug 23 2000 os2_d.b -rw-r--r-- 1 root root 23108 Aug 23 2000 message -rw-r--r-- 1 root root 612 Aug 23 2000 chain.b -rw-r--r-- 1 root root 5824 Aug 23 2000 boot.b -rw-r--r-- 1 root root 0 Aug 25 2000 kernel.h-2.4.0 drwxr-xr-x 2 root root 12288 Nov 10 2000 lost+found lrwxrwxrwx 1 root root 15 Nov 10 2000 kernel.h -> kernel.h-2.2 .16 -rw-r--r-- 1 root root 459736 Nov 10 2000 initrd-2.2.16-22smp.img -rw-r--r-- 1 root root 459092 Nov 10 2000 initrd-2.2.16-22.img -rw------- 1 root root 27648 Nov 10 2000 map -rw-r--r-- 1 root root 512 Nov 10 2000 boot.4800 -rw-r--r-- 1 root root 409 Nov 10 2000 kernel.h-2.2.16 -rw-r--r-- 1 root root 640697 Apr 10 02:03 vmlinuz-2.2.19-7.0.1 -rwxr-xr-x 1 root root 1655517 Apr 10 02:03 vmlinux-2.2.19-7.0.1 -rw-r--r-- 1 root root 11773 Apr 10 02:03 module-info-2.2.19-7.0.1 -rw-r--r-- 1 root root 203905 Apr 10 02:03 System.map-2.2.19-7.0.1 lrwxrwxrwx 1 root root 20 Jun 20 12:29 vmlinuz -> vmlinuz-2.2.1 9-7.0.1 lrwxrwxrwx 1 root root 24 Jun 20 12:29 module-info -> module-in fo-2.2.19-7.0.1 lrwxrwxrwx 1 root root 23 Jun 20 12:37 System.map.bk -> System. map-2.2.16-22smp drwxrwxr-x 2 root root 1024 Jun 20 12:50 bak lrwxrwxrwx 1 root root 23 Jun 20 13:00 System.map -> System.map -2.2.16-22smp [root@petros /boot]# uname -r 2.2.16-22smp
Seems like you haven't changed / reran lilo to actually boot the new kernel. Please see http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html for info on how to do that.
Thanks for the link. The kernel is not upgraded: [root@petros sparky]# uname -r 2.2.19-7.0.1 Here is a vmstat at boot: r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 818728 7960 33008 0 0 68 20 167 262 4 6 89 file-max is at 9182 and inode-max at 32768 I will let it run over night(if it doesn't crash) and see how it goes.
Well I have updated the kernel to 2.2.19-7.0.1 and so far it has not crashed, which is an improvement, but Apache does freeze and needs to be restarted almost weekly. Memory still seems to be an issue(the numbers have decreased with each day of operation, this system has 1gig of ram) This is a vmstat right after the kernel upgrade: r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 779752 11380 48264 0 0 9 5 160 120 1 1 98 This is a vmstat of today: r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 167588 548836 68532 0 0 18 2 250 278 1 4 95 The real problem causing me the most grief is the "Too many open files problem" I keep a log of the file-max values, below are a few samples that show not many files open, yet the high water mark is now at the max. I need the system to release the ones it is not using. I have also provided a few of the error messages I get when the 1st and 3rd column are equal in file-max.: Thu Jun 21 08:55:01 EDT 2001 3687 38 9182 Thu Jun 21 11:45:00 EDT 2001 4512 7 9182 Mon Jun 25 13:35:00 EDT 2001 5576 16 9182 Mon Jun 25 14:25:00 EDT 2001 6585 3 9182 Mon Jun 25 14:45:00 EDT 2001 7702 86 9182 Mon Jun 25 15:05:00 EDT 2001 8713 17 9182 Mon Jun 25 15:15:00 EDT 2001 9182 131 9182 ( once at 9182 2x what I had it set a last week, I start getting "too many open file errors when I login, run man pages etc..; The 1st column never goes back down. This has to be a bug. Any Ideas would be helpful. I am also logging processes and have attached a copy of that file. There was a large jump in used files and no real change in the processes running. Is there a better way to fine out how the files in use are being used??? [sparky@petros sparky]$ su Password: bash: cannot make pipes for command substitution: Too many open files in system bash: cannot make pipes for command substitution: Too many open files in system bash: pipe error: Too many open files in system ast login: Mon Jun 25 12:07:51 2001 from m95.omg.org id: error while loading shared libraries: libc.so.6: cannot open shared object f ile: Error 23 id: error while loading shared libraries: libc.so.6: cannot open shared object f ile: Error 23 id: error while loading shared libraries: libc.so.6: cannot open shared object f ile: Error 23 [: too many arguments id: error while loading shared libraries: libc.so.6: cannot open shared object f ile: Error 23 /bin/hostname: error while loading shared libraries: libc.so.6: cannot open shar ed object file: Error 23 dircolors: error while loading shared libraries: libc.so.6: cannot open shared o bject file: Error 23 grep: error while loading shared libraries: libc.so.6: cannot open shared object file: Error 23 tput: error while loading shared libraries: libncurses.so.5: cannot open shared object file: Error 23 Any help would be great.
If you type (or cut and paste) the following lines while logged in as root cd /proc for i in * ; do echo -n $i ; ls $i/fd/ | wc -l ; done | sort +1n you get a sorted lists of pid's (process id's) and the number of files they have open. It appears something is leaking, and this should show what. Once you know the pid, doing a ls -la /proc/<pid>/ where you replace <pid> with the number with the highest number of fd's, will show which program it is. Could you run this to identify the potential culprit ?
Ok I ran that, there are 44 processes that have about 150 files open each. Here is the output from one of them. Please advise. They seem to be coming from the apache logs. Also found this in the /proc directory r-------- 1 root root 939528192 Jun 27 12:39 kcore ( What is that and should it be deleted??) [root@petros fd]# pwd /proc/16099/fd [root@petros fd]# ls -al total 0 dr-x------ 2 root root 0 Jun 27 12:33 . dr-xr-xr-x 3 nobody nobody 0 Jun 27 12:33 .. lr-x------ 1 root root 64 Jun 27 12:34 0 -> /dev/null l-wx------ 1 root root 64 Jun 27 12:34 1 -> /dev/null lrwx------ 1 root root 64 Jun 27 12:34 10 -> socket:[2207567] l-wx------ 1 root root 64 Jun 27 12:34 100 -> /usr/local/apache /logs/psdef-access_log l-wx------ 1 root root 64 Jun 27 12:34 101 -> /usr/local/apache /logs/ormsc-access_log l-wx------ 1 root root 64 Jun 27 12:34 102 -> /usr/local/apache /logs/orbos-access_log l-wx------ 1 root root 64 Jun 27 12:34 103 -> /usr/local/apache /logs/omaodp-access_log l-wx------ 1 root root 64 Jun 27 12:34 104 -> /usr/local/apache /logs/odp-access_log l-wx------ 1 root root 64 Jun 27 12:34 105 -> /usr/local/apache /logs/mft-access_log l-wx------ 1 root root 64 Jun 27 12:34 106 -> /usr/local/apache /logs/mfg.omg.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 107 -> /usr/local/apache /logs/lsr-access_log l-wx------ 1 root root 64 Jun 27 12:34 108 -> /usr/local/apache /logs/korea-access_log l-wx------ 1 root root 64 Jun 27 12:34 109 -> /usr/local/apache /logs/knowledge-access_log lrwx------ 1 root root 64 Jun 27 12:34 11 -> socket:[2210057] l-wx------ 1 root root 64 Jun 27 12:34 110 -> /usr/local/apache /logs/jsig-access_log l-wx------ 1 root root 64 Jun 27 12:34 111 -> /usr/local/apache /logs/iwg-access_log l-wx------ 1 root root 64 Jun 27 12:34 112 -> /usr/local/apache /logs/inws-access_log l-wx------ 1 root root 64 Jun 27 12:34 113 -> /usr/local/apache /logs/internet-access_log l-wx------ 1 root root 64 Jun 27 12:34 114 -> /usr/local/apache /logs/hr-access_log l-wx------ 1 root root 64 Jun 27 12:34 115 -> /usr/local/apache /logs/fdtf-access_log l-wx------ 1 root root 64 Jun 27 12:34 116 -> /usr/local/apache /logs/ecis-access_log l-wx------ 1 root root 64 Jun 27 12:34 117 -> /usr/local/apache /logs/ecdtf-access_log l-wx------ 1 root root 64 Jun 27 12:34 118 -> /usr/local/apache /logs/eai-access_log l-wx------ 1 root root 64 Jun 27 12:34 119 -> /usr/local/apache /logs/docsec-access_log lrwx------ 1 root root 64 Jun 27 12:34 12 -> socket:[2217588] l-wx------ 1 root root 64 Jun 27 12:34 120 -> /usr/local/apache /logs/dam-access_log l-wx------ 1 root root 64 Jun 27 12:34 121 -> /usr/local/apache /logs/healthcare-access_log l-wx------ 1 root root 64 Jun 27 12:34 122 -> /usr/local/apache /logs/corbagis-access_log l-wx------ 1 root root 64 Jun 27 12:34 123 -> /usr/local/apache /logs/c4i-access_log l-wx------ 1 root root 64 Jun 27 12:34 124 -> /usr/local/apache /logs/boi-access_log l-wx------ 1 root root 64 Jun 27 12:34 125 -> /usr/local/apache /logs/cem-access_log l-wx------ 1 root root 64 Jun 27 12:34 126 -> /usr/local/apache /logs/benchmark-access_log l-wx------ 1 root root 64 Jun 27 12:34 127 -> /usr/local/apache /logs/adtf-access_log l-wx------ 1 root root 64 Jun 27 12:34 128 -> /usr/local/apache /logs/adss-access_log l-wx------ 1 root root 64 Jun 27 12:34 129 -> /usr/local/apache /logs/adm-access_log lrwx------ 1 root root 64 Jun 27 12:34 13 -> socket:[2212509] l-wx------ 1 root root 64 Jun 27 12:34 130 -> /usr/local/apache /logs/cost1-access_log l-wx------ 1 root root 64 Jun 27 12:34 131 -> /usr/local/apache /logs/p4i-access_log l-wx------ 1 root root 64 Jun 27 12:34 132 -> /usr/local/apache /logs/secure.omg.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 133 -> /usr/local/apache /logs/www.corba.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 134 -> /usr/local/apache /logs/www.uml.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 135 -> /usr/local/apache /logs/backup_access_log l-wx------ 1 root root 64 Jun 27 12:34 136 -> /usr/local/apache /logs/backup_access_log l-wx------ 1 root root 64 Jun 27 12:34 137 -> /usr/local/apache /logs/intranet_access_log l-wx------ 1 root root 64 Jun 27 12:34 138 -> /usr/local/apache /logs/production_access_log l-wx------ 1 root root 64 Jun 27 12:34 139 -> /home/apache_logs /access_log lrwx------ 1 root root 64 Jun 27 12:34 14 -> socket:[2216180] l-wx------ 1 root root 64 Jun 27 12:34 140 -> /usr/local/apache /logs/www.omgspecifications.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 141 -> /usr/local/apache /logs/www.omgspecs.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 142 -> /home/apache_logs /access_log l-wx------ 1 root root 64 Jun 27 12:34 143 -> /usr/local/apache /logs/www.modeldrivenarchitecture.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 144 -> /usr/local/apache /logs/www.dopg.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 145 -> /usr/local/apache /logs/www.corba.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 146 -> /usr/local/apache /logs/infosell-access_log l-wx------ 1 root root 64 Jun 27 12:34 147 -> /usr/local/apache /logs/testpass.omg.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 148 -> /usr/local/apache /logs/test.omg.org-access_log l-wx------ 1 root root 64 Jun 27 12:34 149 -> /usr/local/apache /logs/httpd.lock.16075 (deleted) l-wx------ 1 root root 64 Jun 27 12:34 15 -> /usr/local/apache/ logs/error_log l-wx------ 1 root root 64 Jun 27 12:34 150 -> /usr/local/apache /logs/ssl_mutex.16074 lrwx------ 1 root root 64 Jun 27 12:34 151 -> socket:[2227070] lrwx------ 1 root root 64 Jun 27 12:34 152 -> socket:[2226976] lrwx------ 1 root root 64 Jun 27 12:34 153 -> socket:[2227221] lrwx------ 1 root root 64 Jun 27 12:34 154 -> socket:[2227272] lrwx------ 1 root root 64 Jun 27 12:34 155 -> socket:[2228130] lrwx------ 1 root root 64 Jun 27 12:34 156 -> socket:[2248946] lrwx------ 1 root root 64 Jun 27 12:34 157 -> socket:[2229441] lrwx------ 1 root root 64 Jun 27 12:34 158 -> socket:[2253248] lrwx------ 1 root root 64 Jun 27 12:34 159 -> socket:[2253158] l-wx------ 1 root root 64 Jun 27 12:34 16 -> /usr/local/apache/ logs/secure_error_log lrwx------ 1 root root 64 Jun 27 12:34 160 -> socket:[2255199] lrwx------ 1 root root 64 Jun 27 12:34 161 -> socket:[2256130] lrwx------ 1 root root 64 Jun 27 12:34 162 -> socket:[2255229] lrwx------ 1 root root 64 Jun 27 12:34 163 -> socket:[2258072] lrwx------ 1 root root 64 Jun 27 12:34 164 -> socket:[2269648] lrwx------ 1 root root 64 Jun 27 12:34 165 -> socket:[2280845] lrwx------ 1 root root 64 Jun 27 12:34 166 -> socket:[2278829] lrwx------ 1 root root 64 Jun 27 12:34 167 -> socket:[2280894] lr-x------ 1 root root 64 Jun 27 12:34 169 -> pipe:[2291178] l-wx------ 1 root root 64 Jun 27 12:34 17 -> /home/httpd/html/s urvey/logs/survey-error_log l-wx------ 1 root root 64 Jun 27 12:34 170 -> pipe:[2291178] lrwx------ 1 root root 64 Jun 27 12:34 171 -> socket:[2312763] l-wx------ 1 root root 64 Jun 27 12:34 18 -> /usr/local/apache/ logs/doc-error_log l-wx------ 1 root root 64 Jun 27 12:34 19 -> /usr/local/apache/ logs/utilities-error_log l-wx------ 1 root root 64 Jun 27 12:34 2 -> /home/apache_logs/e rror_log l-wx------ 1 root root 64 Jun 27 12:34 20 -> /usr/local/apache/ logs/transport-error_log l-wx------ 1 root root 64 Jun 27 12:34 21 -> /usr/local/apache/ logs/testsig-error_log l-wx------ 1 root root 64 Jun 27 12:34 22 -> /usr/local/apache/ logs/telecom-error_log l-wx------ 1 root root 64 Jun 27 12:34 23 -> /usr/local/apache/ logs/swradio-error_log l-wx------ 1 root root 64 Jun 27 12:34 24 -> /usr/local/apache/ logs/space-error_log l-wx------ 1 root root 64 Jun 27 12:34 25 -> /usr/local/apache/ logs/simsig-error_log l-wx------ 1 root root 64 Jun 27 12:34 26 -> /usr/local/apache/ logs/sdo-error_log l-wx------ 1 root root 64 Jun 27 12:34 27 -> /usr/local/apache/ logs/secsig-error_log l-wx------ 1 root root 64 Jun 27 12:34 28 -> /usr/local/apache/ logs/rtws-error_log l-wx------ 1 root root 64 Jun 27 12:34 29 -> /usr/local/apache/ logs/retail-error_log l-wx------ 1 root root 64 Jun 27 12:34 30 -> /usr/local/apache/ logs/realtime-error_log l-wx------ 1 root root 64 Jun 27 12:34 31 -> /usr/local/apache/ logs/psdef-error_log l-wx------ 1 root root 64 Jun 27 12:34 32 -> /usr/local/apache/ logs/ormsc-error_log l-wx------ 1 root root 64 Jun 27 12:34 33 -> /usr/local/apache/ logs/orbos-error_log l-wx------ 1 root root 64 Jun 27 12:34 34 -> /usr/local/apache/ logs/omaodp-error_log l-wx------ 1 root root 64 Jun 27 12:34 35 -> /usr/local/apache/ logs/odp-error_log l-wx------ 1 root root 64 Jun 27 12:34 36 -> /usr/local/apache/ logs/mft-error_log l-wx------ 1 root root 64 Jun 27 12:34 37 -> /usr/local/apache/ logs/mfg.omg.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 38 -> /usr/local/apache/ logs/lsr-error_log l-wx------ 1 root root 64 Jun 27 12:34 39 -> /usr/local/apache/ logs/korea-error_log lrwx------ 1 root root 64 Jun 27 12:34 4 -> socket:[2167362] l-wx------ 1 root root 64 Jun 27 12:34 40 -> /usr/local/apache/ logs/knowledge-error_log l-wx------ 1 root root 64 Jun 27 12:34 41 -> /usr/local/apache/ logs/jsig-error_log l-wx------ 1 root root 64 Jun 27 12:34 42 -> /usr/local/apache/ logs/iwg-error_log l-wx------ 1 root root 64 Jun 27 12:34 43 -> /usr/local/apache/ logs/inws-error_log l-wx------ 1 root root 64 Jun 27 12:34 44 -> /usr/local/apache/ logs/internet-error_log l-wx------ 1 root root 64 Jun 27 12:34 45 -> /usr/local/apache/ logs/hr-error_log l-wx------ 1 root root 64 Jun 27 12:34 46 -> /usr/local/apache/ logs/fdtf-error_log l-wx------ 1 root root 64 Jun 27 12:34 47 -> /usr/local/apache/ logs/ecis-error_log l-wx------ 1 root root 64 Jun 27 12:34 48 -> /usr/local/apache/ logs/ecdtf-error_log l-wx------ 1 root root 64 Jun 27 12:34 49 -> /usr/local/apache/ logs/eai-error_log lrwx------ 1 root root 64 Jun 27 12:34 5 -> socket:[2166712] l-wx------ 1 root root 64 Jun 27 12:34 50 -> /usr/local/apache/ logs/docsec-error_log l-wx------ 1 root root 64 Jun 27 12:34 51 -> /usr/local/apache/ logs/dam-error_log l-wx------ 1 root root 64 Jun 27 12:34 52 -> /usr/local/apache/ logs/healthcare-error_log l-wx------ 1 root root 64 Jun 27 12:34 53 -> /usr/local/apache/ logs/corbagis-error_log l-wx------ 1 root root 64 Jun 27 12:34 54 -> /usr/local/apache/ logs/c4i-error_log l-wx------ 1 root root 64 Jun 27 12:34 55 -> /usr/local/apache/ logs/boi-error_log l-wx------ 1 root root 64 Jun 27 12:34 56 -> /usr/local/apache/ logs/cem-error_log l-wx------ 1 root root 64 Jun 27 12:34 57 -> /usr/local/apache/ logs/benchmark-error_log l-wx------ 1 root root 64 Jun 27 12:34 58 -> /usr/local/apache/ logs/adtf-error_log l-wx------ 1 root root 64 Jun 27 12:34 59 -> /usr/local/apache/ logs/adss-error_log lrwx------ 1 root root 64 Jun 27 12:34 6 -> socket:[2167328] l-wx------ 1 root root 64 Jun 27 12:34 60 -> /usr/local/apache/ logs/adm-error_log l-wx------ 1 root root 64 Jun 27 12:34 61 -> /usr/local/apache/ logs/cost1-error_log l-wx------ 1 root root 64 Jun 27 12:34 62 -> /usr/local/apache/ logs/p4i-error_log l-wx------ 1 root root 64 Jun 27 12:34 63 -> /usr/local/apache/ logs/secure.omg.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 64 -> /usr/local/apache/ logs/www.corba.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 65 -> /usr/local/apache/ logs/www.uml.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 66 -> /usr/local/apache/ logs/backupall_error_log l-wx------ 1 root root 64 Jun 27 12:34 67 -> /usr/local/apache/ logs/backup_error_log l-wx------ 1 root root 64 Jun 27 12:34 68 -> /usr/local/apache/ logs/intranet_error_log l-wx------ 1 root root 64 Jun 27 12:34 69 -> /usr/local/apache/ logs/production_error_log lr-x------ 1 root root 64 Jun 27 12:34 7 -> pipe:[2293977] l-wx------ 1 root root 64 Jun 27 12:34 70 -> /home/apache_logs/ error_log l-wx------ 1 root root 64 Jun 27 12:34 71 -> /usr/local/apache/ logs/www.omgspecifications.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 72 -> /usr/local/apache/ logs/www.omgspecs.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 73 -> /usr/local/apache/ logs/www.modeldrivenarchitecture.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 74 -> /usr/local/apache/ logs/www.dopg.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 75 -> /usr/local/apache/ logs/infosell-error_log l-wx------ 1 root root 64 Jun 27 12:34 76 -> /usr/local/apache/ logs/testpass.omg.org-error_log l-wx------ 1 root root 64 Jun 27 12:34 77 -> /usr/local/apache/ logs/test.omg.org-error_log lrwx------ 1 root root 64 Jun 27 12:34 78 -> socket:[2165964] lrwx------ 1 root root 64 Jun 27 12:34 79 -> socket:[2165965] lrwx------ 1 root root 64 Jun 27 12:34 8 -> socket:[2210073] l-wx------ 1 root root 64 Jun 27 12:34 80 -> /usr/local/apache/ logs/ssl_engine_log l-wx------ 1 root root 64 Jun 27 12:34 81 -> /usr/local/apache/ logs/ssl_mutex.16074 l-wx------ 1 root root 64 Jun 27 12:34 82 -> /usr/local/apache/ logs/ip_log l-wx------ 1 root root 64 Jun 27 12:34 83 -> /home/apache_logs/ access_log l-wx------ 1 root root 64 Jun 27 12:34 84 -> /usr/local/apache/ logs/secure_access_log l-wx------ 1 root root 64 Jun 27 12:34 85 -> /usr/local/apache/ logs/ssl_request_log l-wx------ 1 root root 64 Jun 27 12:34 86 -> /home/httpd/html/s urvey/logs/survey-access_log l-wx------ 1 root root 64 Jun 27 12:34 87 -> /usr/local/apache/ logs/doc-access_log l-wx------ 1 root root 64 Jun 27 12:34 88 -> /usr/local/apache/ logs/utilities-access_log l-wx------ 1 root root 64 Jun 27 12:34 89 -> /usr/local/apache/ logs/transport-access_log lrwx------ 1 root root 64 Jun 27 12:34 9 -> socket:[2206085] l-wx------ 1 root root 64 Jun 27 12:34 90 -> /usr/local/apache/ logs/testsig-access_log l-wx------ 1 root root 64 Jun 27 12:34 91 -> /usr/local/apache/ logs/telecom-access_log l-wx------ 1 root root 64 Jun 27 12:34 92 -> /usr/local/apache/ logs/swradio-access_log l-wx------ 1 root root 64 Jun 27 12:34 93 -> /usr/local/apache/ logs/space-access_log l-wx------ 1 root root 64 Jun 27 12:34 94 -> /usr/local/apache/ logs/simsig-access_log l-wx------ 1 root root 64 Jun 27 12:34 95 -> /usr/local/apache/ logs/sdo-access_log l-wx------ 1 root root 64 Jun 27 12:34 96 -> /usr/local/apache/ logs/secsig-access_log l-wx------ 1 root root 64 Jun 27 12:34 97 -> /usr/local/apache/ logs/rtws-access_log l-wx------ 1 root root 64 Jun 27 12:34 98 -> /usr/local/apache/ logs/retail-access_log l-wx------ 1 root root 64 Jun 27 12:34 99 -> /usr/local/apache/ logs/realtime-access_log [root@petros fd]#
kcore is a _virtual_ file that can be used to debug the kernel; it doesn't take space and should not be deleted. It appears that apache is keeping files open too long, that appears to be an apache bug not a kernel bug, reassinging to the apache package.
Is anyone looking into this. I have a major problem here and havn't heard back in over 2 weeks!!! What is this Apache problem? Fix????
Thanks for the report. This is a mass bug update; since this release of Red Hat Linux is no longer supported, please either: a) try and reproduce the bug with a supported version of Red Hat Enterprise Linux or Fedora Core, and re-open this bug as appropriate after changing the Product field, or, b) if relevant, try and reproduce this bug using the current version of the upstream package, and report the bug upstream.