Forum Moderators: phranque
Webmin shows:
Process ID Owner CPU Command
----------------------------------------
11418 apache 65.2 % /usr/sbin/httpd
30681 mysql 5.3 % /usr/libexec/mysqld ...
12936 apache 0.9 % /usr/sbin/httpd
12930 apache 0.5 % /usr/sbin/httpd
12935 apache 0.5 % /usr/sbin/httpd
12829 apache 0.4 % /usr/sbin/httpd
12852 apache 0.4 % /usr/sbin/httpd
12854 apache 0.4 % /usr/sbin/httpd
12587 apache 0.3 % /usr/sbin/httpd
12686 apache 0.3 % /usr/sbin/httpd
This is happening every day now. It doesn't just happen for a few seconds but for hours - until I restart apache. That particular process 11418 has been running for 48 minutes now. Earlier another rogue process was running for 2+ hours.
I do have some big reports which users can generate, and I think some of them peform screen scraping (acceptable). So how do I tell which user or IP that process is coming from?
I can run netstat -en and this shows me all IP's who are connected to port 80 but I can't tie them up to process 11418 which started 48 minutes ago.
Any other tool I can use to track this down?
lsof ¦ grep TCP
Except change the pipe into a FULL pipe with no break as this forum auto splits pipe character for some reason!Security most likely..
If you don't have LSOF installed then download it from a friendly repo and it will be your good friend :) as although it is complex it is very very useful I find...
Please keep us updated on this. Im curious to know what the culprit has been doing!
Here is the output from lsof ¦ grep TCP
dovecot 2721 root 5u IPv4 5921 TCP *:pop3s (LISTEN)
master 2779 root 11u IPv4 6118 TCP *:smtp (LISTEN)
httpd 2800 root 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 4933 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 4978 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 5238 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 5496 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 5703 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 6212 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 6772 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 7942 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 8205 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 8609 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 8612 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 9786 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 10018 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 10357 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 10852 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 11467 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 11538 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 11638 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 12085 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 12201 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 12933 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 12945 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 13386 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 13405 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 13790 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 13947 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 13989 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
pop3-logi 14207 dovecot 1u IPv4 5921 TCP *:pop3s (LISTEN)
smtpd 14211 postfix 6u IPv4 6118 TCP *:smtp (LISTEN)
smtpd 14211 postfix 9u IPv4 144317 TCP widgets.com:smtp->cmung1049.cmu.carnet.hr:2404 (ESTABLISHED)
pop3-logi 14271 dovecot 1u IPv4 5921 TCP *:pop3s (LISTEN)
httpd 14325 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14325 apache 25u IPv4 143628 TCP widgets.com:http->host86-149-20-105.range86-149.btcentralplus.com:1568 (CLOSE_WAIT)
smtpd 14334 postfix 6u IPv4 6118 TCP *:smtp (LISTEN)
smtpd 14334 postfix 9u IPv4 143625 TCP widgets.com:smtp->cmung1049.cmu.carnet.hr:2038 (ESTABLISHED)
smtpd 14345 postfix 6u IPv4 6118 TCP *:smtp (LISTEN)
smtpd 14345 postfix 9u IPv4 142656 TCP widgets.com:smtp->pool-71-111-100-231.ptldor.dsl-w.verizon.net:3063 (ESTABLISHED)
smtpd 14351 postfix 6u IPv4 6118 TCP *:smtp (LISTEN)
smtpd 14351 postfix 9u IPv4 143823 TCP widgets.com:smtp->pool-71-111-100-231.ptldor.dsl-w.verizon.net:4363 (ESTABLISHED)
httpd 14393 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14394 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14395 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14406 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14408 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14409 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14456 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14458 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14484 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14485 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14486 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14552 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14553 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14553 apache 25u IPv4 144320 TCP widgets.com:http->reverse.keele.netcentral.co.uk:33102 (ESTABLISHED)
httpd 14554 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
httpd 14555 apache 3u IPv4 6265 TCP widgets.com:http (LISTEN)
pop3-logi 14634 dovecot 1u IPv4 5921 TCP *:pop3s (LISTEN)
Doesn't seem to be much in there.
Looking at webmin running processes shows this:
Process ID Owner CPU Command
---------------------------------------
11467 apache 94.5 % /usr/sbin/httpd
13790 apache 72.9 % /usr/sbin/httpd
8951 mysql 6.5 % /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/li ...
14506 root 1.0 % /usr/libexec/webmin/proc/index_cpu.cgi
14393 apache 0.8 % /usr/sbin/httpd
14409 apache 0.7 % /usr/sbin/httpd
14457 apache 0.5 % /usr/sbin/httpd
14325 apache 0.4 % /usr/sbin/httpd
14395 apache 0.4 % /usr/sbin/httpd
14459 apache 0.3 % /usr/sbin/httpd
14394 apache 0.2 % /usr/sbin/httpd
14406 apache 0.2 % /usr/sbin/httpd
14408 apache 0.2 % /usr/sbin/httpd
14456 apache 0.2 % /usr/sbin/httpd
14458 apache 0.2 % /usr/sbin/httpd
14486 apache 0.2 % /usr/sbin/httpd
14379 apache 0.1 % /usr/sbin/httpd
14484 apache 0.1 % /usr/sbin/httpd
1 root 0.0 % init [3]
That can't be right can it? CPU is core2duo xeon which is holding up well but the 94% and 72% for those top two processes is clearly wrong.
I don't know if the lsof thing was meant to list open files. Webmin does that:
For process /usr/sbin/httpd (PID 11467)
Open files
File Descriptor Type File size Inode Path
Current dir Directory 4096 2 /
Root dir Directory 4096 2 /
Program code Regular file 259360 9593359 /usr/sbin/httpd
Shared library Regular file 81236 9595678 /usr/lib/libaprutil-0.so.0.9.4
Shared library Regular file 82320 9593626 /usr/lib/libsasl2.so.2.0.19
Shared library Regular file 7004 3162225 /lib/libcom_err.so.2.1
Shared library Regular file 50672 3162239 /lib/tls/librt-2.3.4.so
Shared library Regular file 28476 3162283 /lib/libcrypt-2.3.4.so
Shared library Regular file 82944 9594008 /usr/lib/libgssapi_krb5.so.2.2
Shared library Regular file 5820 5734516 /usr/lib/httpd/modules/mod_dir.so
Shared library Regular file 63640 3165508 /lib/libpcre.so.0.0.1
Shared library Regular file 415188 9593413 /usr/lib/libkrb5.so.3.2
Shared library Regular file 6944 5734506 /usr/lib/httpd/modules/mod_auth_dbm.so
Shared library Regular file 8568 5734519 /usr/lib/httpd/modules/mod_expires.so
Shared library Regular file 8608 5734539 /usr/lib/httpd/modules/mod_setenvif.so
Shared library Regular file 26532 5734533 /usr/lib/httpd/modules/mod_negotiation.so
Shared library Regular file 5824 5734436 /usr/lib/httpd/modules/mod_actions.so
Shared library Regular file 9276 5734486 /usr/lib/httpd/modules/mod_alias.so
Shared library Regular file 53920 5734538 /usr/lib/httpd/modules/mod_rewrite.so
Shared library Regular file 19008 5734530 /usr/lib/httpd/modules/mod_mem_cache.so
Shared library Regular file 4764 5734542 /usr/lib/httpd/modules/mod_suexec.so
Shared library Regular file 20188 5734512 /usr/lib/httpd/modules/mod_cgi.so
Shared library Regular file 6788 5734543 /usr/lib/httpd/modules/mod_unique_id.so
Shared library Regular file 48548 9593245 /usr/lib/liblber-2.2.so.7.0.6
Shared library Regular file 845624 3166397 /lib/tls/i686/libdb-4.2.so
Shared library Regular file 941024 3165506 /lib/libcrypto.so.0.9.7a
Shared library Regular file 123496 9592735 /usr/lib/libexpat.so.0.5.0
Shared library Regular file 1529204 3162249 /lib/tls/libc-2.3.4.so
Shared library Regular file 47404 3162161 /lib/libnss_files-2.3.4.so
Shared library Regular file 202976 9595979 /usr/lib/libldap-2.2.so.7.0.6
Shared library Regular file 144172 9593340 /usr/lib/libpng12.so.0.1.2.7
Shared library Regular file 648858 100183 /usr/lib/httpd/modules/mod_security2.so
Shared library Regular file 16732 3162263 /lib/libdl-2.3.4.so
Shared library Regular file 189696 9590443 /usr/lib/libcurl.so.3.0.0
Shared library Regular file 22580 5734510 /usr/lib/httpd/modules/mod_cache.so
Shared library Regular file 193700 9589259 /usr/lib/libidn.so.11.4.6
Shared library Regular file 381488 131656 /usr/lib/php/extensions/no-debug-non-zts-20060613/apc.so
Shared library Regular file 138260 9595672 /usr/lib/libapr-0.so.0.9.4
Shared library Regular file 213600 3165507 /lib/libssl.so.0.9.7a
Shared library Regular file 965696 9593802 /usr/lib/libxml2.so.2.6.16
Shared library Regular file 5052 5734518 /usr/lib/httpd/modules/mod_env.so
Shared library Regular file 7676 5734501 /usr/lib/httpd/modules/mod_auth.so
Shared library Regular file 112168 3162182 /lib/ld-2.3.4.so
Shared library Regular file 136016 9593438 /usr/lib/libk5crypto.so.3.0
Shared library Regular file 13276 5734531 /usr/lib/httpd/modules/mod_mime.so
Shared library Regular file 6428 5734423 /usr/lib/httpd/modules/mod_access.so
Shared library Regular file 18432 5734527 /usr/lib/httpd/modules/mod_log_config.so
Shared library Regular file 213772 3162251 /lib/tls/libm-2.3.4.so
Shared library Regular file 19632 5734532 /usr/lib/httpd/modules/mod_mime_magic.so
Shared library Regular file 97120 3162260 /lib/libnsl-2.3.4.so
Shared library Regular file 26748 5734507 /usr/lib/httpd/modules/mod_auth_digest.so
Shared library Regular file 8620 9592758 /usr/lib/libpcreposix.so.0.0.0
Shared library Regular file 28640 5734509 /usr/lib/httpd/modules/mod_autoindex.so
Shared library Regular file 63624 9590436 /usr/lib/libz.so.1.2.1.2
Shared library Regular file 35904 5734524 /usr/lib/httpd/modules/mod_include.so
Shared library Regular file 107800 3162267 /lib/tls/libpthread-2.3.4.so
Shared library Regular file 81120 3162206 /lib/libresolv-2.3.4.so
Shared library Regular file 5595608 5734408 /usr/lib/httpd/modules/libphp5.so
Shared library Regular file 1394724 9716706 /usr/lib/mysql/libmysqlclient.so.15.0.0
del Regular file
6420 /dev/zero
del Regular file
2588674 /secondary/tmp/apc.kht0Tl
0r Character special
473 /dev/null
1w Character special
473 /dev/null
2w Regular file 463923 7012371 /secondary/var/log/httpd/error_log
4w Regular file 13211625 3325954 /secondary/a_log/modsec_audit.log
5w Regular file 3045474 3325959 /secondary/a_log/modsec_debug.log
6r fifo
6287 pipe
7w fifo
6287 pipe
8w Regular file 463923 7012371 /secondary/var/log/httpd/error_log
9w Regular file 29442 3325985 /secondary/a_log/hl_e_log
10w Regular file 575240 3325955 /secondary/a_log/c_e_log
11w Regular file 2729747 3325956 /secondary/a_log/fs_com_e_log
12w Regular file 44718 3325957 /secondary/a_log/js_e_log
13w Regular file 5439880 3325958 /secondary/a_log/fs_e_log
14w Regular file
7012359 /secondary/var/log/httpd/access_log
15w Regular file 128209 3325986 /secondary/a_log/hl_a_log
16w Regular file 61804369 3325960 /secondary/a_log/c_a_log
17w Regular file 1284978 3325961 /secondary/a_log/fs_com_a_log
18w Regular file 1142788 3325962 /secondary/a_log/js_a_log
19w Regular file 25036069 3325965 /secondary/a_log/fs_a_log
20u Regular file
8306691 /tmp/.apc.LZOYz7 (deleted)
21u Regular file
8306692 /tmp/.apc.SSuYfT (deleted)
22u Regular file
8306693 /tmp/.apc.W4mYVE (deleted)
23u Regular file
8306694 /tmp/.apc.a5LYBq (deleted)
24u Regular file
8306695 /tmp/.apc.XQoZhc (deleted)
25u sock
78835 can't identify protocol
[edited by: Frank_Rizzo at 8:56 am (utc) on Sep. 6, 2007]
The LSOF was meant to show process ID against IP or name of the client that is using it!
It does on my unix install...
What OS and version are you running please?
This will help with troublehooting.
Do you have IP tables installed also?
How is it setup if you do?
Re the process percentages shown....
Most strange! They are incorrect it seems!
Am I correct in thinking you are hosting and have Virtual Hosts setup? Are you on the latest version of apache? if not what version? is it a bug?
Please elaborate on your setup a little..
lsof version 4.72
Linux widgets.co.uk 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 26 14:30:58 EDT 2007 i686 i686 i386 GNU/Linux
-------------------
Here's the latest CPU hogs as per Webmin:
CPU load averages: 2.77 (1 mins) , 3.00 (5 mins) , 3.05 (15 mins)
CPU type: Intel(R) Xeon(R) CPU 3060 @ 2.40GHz (2400 MHz)
Process ID Owner CPU Command
3343 apache 64.7 % /usr/sbin/httpd
3597 apache 60.8 % /usr/sbin/httpd
8951 mysql 5.9 % /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/li ...
5543 apache 1.0 % /usr/sbin/httpd
5384 apache 0.7 % /usr/sbin/httpd
Process 3343 started 11:35 and been running for 01:29:23
Process 3597 started 11:59 and been running for 01:10:30
I have now toasted those processes. But they will be back!
Latest Stable release is v 2.2.4 and it has a lot of bug fixes since the version you are running.
Highlights at the top of a very long list are
*) mod_isapi: Correctly present SERVER_PORT_SECURE.
PR: 40573. [Matt Eaton <asf divinehawk.com>]*) Allow htcacheclean, httxt2dbm, and fcgistarter to link apr/apr-util
statically like the older support programs.
[Eric Covener <covener gmail.com>]*) core: Fix NONBLOCK status of listening sockets on restart/graceful
PR 37680. [Darius Davis <darius-abz free-range.com.au>]*) mod_deflate: Rework inflate output and deflate output filter to fix several
issues: Incorrect handling of flush buckets, potential memory leaks,
excessive memory usage in inflate output filter for large compressed
content. PR 39854. [Ruediger Pluem, Nick Kew, Justin Erenkrantz]*) mod_mem_cache: Memory leak fix: Unconditionally free the buffer.
...................................++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++many more
[httpd.apache.org...]
I have a vague recollection of having similiar anomilies of high processor readings for the same processes while using that version.
My server raid array failed b4 I got chance to fix it so I was forced to update!
Running the latest stable version is always good though to rule out 'fixed bugs' as being the cause of your problem....
With that said I am only on the same version as you but ending 59.
edited
Heres a very useful repo that has lots of current rpms in it..think Im going to upgrade myself now I have thought about it!
[jasonlitka.com...]
I don't know if it is this is related but I also have intermittent problems with yum, rpm and wget.
[root@widgets]# yum update
Setting up Update Process
Setting up repositories
and just sit there doing nothing
[root@widgets]# wget http //freshmeat.net/redir/apachetop/44014/url_tgz/apachetop-0.12.6.tar.gz
--16:23:18-- http //freshmeat.net/redir/apachetop/44014/url_tgz/apachetop-0.12.6.tar.gz
=> `apachetop-0.12.6.tar.gz'
Resolving freshmeat.net... 66.35.250.168
Connecting to freshmeat.net¦66.35.250.168¦:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http //www.webta.org/apachetop/apachetop-0.12.6.tar.gz [following]
--16:23:19-- http //www.webta.org/apachetop/apachetop-0.12.6.tar.gz
=> `apachetop-0.12.6.tar.gz'
Resolving www.webta.org... 70.84.240.138
Connecting to www.webta.org¦70.84.240.138¦:80...
Same with that. Just waits on the Connecting to www.webta... and does nothing.
Maybe there is a network card issue here.
If I shutdown iptables I can yum, rpm, wget no problem at all. If I start it up and apply the ban_list I can't again.
The ban_list actually contains 320 lines of:
/sbin/iptables -I INPUT -s 123.123.123.0/19 -j DROP
/sbin/iptables -I INPUT -s 222.222.222.22 -j DROP
Could the sheer number be a problem here? Maybe I have inadvertently dropped the web hosters dns or router or something?
It can be very stressful if something goes wrong!
But with that said, I think it may help resolve your first bug regarding the high CPU reading...
incidentally, it doesnt sound as if the actual processor is being flogged that hard....just that apache thinks it is for whatever reason!
Hmm. Don't know if this unable to yum update / wget is connected to the httpd fault but the problem is to do with iptables.
If I shutdown iptables I can yum, rpm, wget no problem at all. If I start it up and apply the ban_list I can't again.The ban_list actually contains 320 lines of:
/sbin/iptables -I INPUT -s 123.123.123.0/19 -j DROP
/sbin/iptables -I INPUT -s 222.222.222.22 -j DROPCould the sheer number be a problem here? Maybe I have inadvertently dropped the web hosters dns or router or something?
Hmm.
I cant see this being connected to the apache processor issue due to the fact the connection has already been made by way of the fact that the apache process instance is open..
Strange though, it does indeed sound like you may either
1/ have a conflicting rule in there
2/ have a rule banning packets you need!
I dont believe the amount of banned IPs is the problem however I have never personally used as many as 300 IP bans myself.
I think it may be better to focus on banning the service or packet pattern or scan type rather than such a big ban list. or is this ban list of specific users who were abusing the site rather than potential hackers?
You could always cut the list down to say 50 late one night and see if that resolves your problem, then add say 100 back and restart iptables, test again etc until you come upon the bad rule!
--
I just tried a quick update to jason's 2.2 version of httpd. Had to roll back as the config file looks a lot different. Will try this again later.
Your V2 config files will work 100% fine with V2.2
as I upgraded myself earlier this evening after getting paranoid :)
This is whats changed
mod_imap has been renamed to mod_imagemap
mod_auth has been split up into mod_auth_basic, mod_authn_file, mod_authz_user, and mod_authz_groupfile
mod_access has been renamed to mod_authz_host
mod_auth_ldap has been renamed to mod_authnz_ldap
Upgraded to require the APR 1.0 API.
Updated bundled PCRE version to 5.0
and this is what Apache themselves say about the upgrade
Your existing version 2.0 config files and startup scripts can usually be used unchanged in version 2.2. Some small adjustments may be necessary for particular configurations as discussed below. In addition, if you dynamically load the standard modules using the LoadModule directive, then you will need to account for the module name changes mentioned above.If you choose to use the new default configuration file for version 2.2, you will find that it has been greatly simplified by removing all but the most essential configuration settings. A set of example configuration settings for more advanced features is present in the conf/extra/ directory of the installed server. Default configuration files are installed in the conf/original directory.
Some runtime configuration changes that you may notice:
The apachectl option startssl is no longer available. To enable SSL support, you should edit httpd.conf to include the relevant mod_ssl directives and then use apachectl start to start the server. An example configuration to activate mod_ssl has been included in conf/extra/httpd-ssl.conf.
The default setting of UseCanonicalName is now Off. If you did not have this directive in your config file, you can add UseCanonicalName On to retain the old behavior.
The module mod_userdir will no longer act on requests unless a UserDir directive specifying a directory name is present in the config file. To restore the old default behavior, place the directive UserDir public_html in your config file.
The directive AuthDigestFile from mod_auth_digest has been merged with AuthUserFile and is now part of mod_authn_file.
I am using Centos 4.5 also and a very similair setup to you and can confirm the above is indeed true!
hth
First thing I did was to prepare the httpd.conf file with a merge of the existing httpd.conf and what the new one tried to set it to. Yum removed 2.0.52, yum installed 2.2, copied httpd.conf.new -> httpd.conf
All working fine now but I'll wait until tomorrow morning to be confident that the httpd hog problem has gone.
Ohhh. One other good thing about 2.2 is that it has fixed a segfault problem I had for over a year. This only happened when modsec was running and I couldn't get rid of it. Happened with different hardware, Centos 4.4, 4.5, modsec 1.9 to 2.1.3.
Really pleased to see that the segfaults and glibc memory errors have gone. Looks like this upgrade could be a double result :)
Thanks for the encouragement to upgrade!
[edited by: Frank_Rizzo at 11:58 pm (utc) on Sep. 6, 2007]
I tried the upgrade again and it went a bit better this time.
First thing I did was to prepare the httpd.conf file with a merge of the existing httpd.conf and what the new one tried to set it to. Yum removed 2.0.52, yum installed 2.2, copied httpd.conf.new -> httpd.confAll working fine now but I'll wait until tomorrow morning to be confident that the httpd hog problem has gone.
Ohhh. One other good thing about 2.2 is that it has fixed a segfault problem I had for over a year. This only happened when modsec was running and I couldn't get rid of it. Happened with different hardware, Centos 4.4, 4.5, modsec 1.9 to 2.1.3.
Really pleased to see that the segfaults and glibc memory errors have gone. Looks like this upgrade could be a double result :)
Thanks for the encouragement to upgrade!
Excellent news!
Glad it has fixed some past issues.
I love it when an upgrade goes smoothly :)
Fingers crossed the cpu hog problem has gone. I would be interested to know if this has indeed cured it..
I would bet a pound to a penny it has though especially if the segfaults and glibc memory errors have gone.
Now I've just got to persuade myself that my impending kernel upgrade will go so smoothly!
2.2 looks much better at using resources - CPU time for regular usage is now showing around 0.1 to 0.2% per slot whereas with 2.0.52 it was around 0.3 to 0.9%. Memory usage has dropped too from about 60-80M per slot to 25-35M.
I said the main reason why I held off from upgrading was due to time. I had thought I would have had to manually compile httpd from source and was expecting all the problems associated with that kind of procedure.
Why I thought that was because 2.0.5x is the only version you can yum update. I think even with centos plus that is the 'latest' version. So that jason site is top notch. He's created the packages for the 2.2, php 5.2.4, mysql 5.0.46. That's a great find there.
I was on a roll this morning and updated them all including the kernel . Took no more than 3 minutes to do the lot!
One gotcha - upgrading mysql blanked out the root password. That's the only post upgrade thing I had to sort out.
Yes all working fine now.
2.2 looks much better at using resources - CPU time for regular usage is now showing around 0.1 to 0.2% per slot whereas with 2.0.52 it was around 0.3 to 0.9%. Memory usage has dropped too from about 60-80M per slot to 25-35M.I said the main reason why I held off from upgrading was due to time. I had thought I would have had to manually compile httpd from source and was expecting all the problems associated with that kind of procedure.
Why I thought that was because 2.0.5x is the only version you can yum update. I think even with centos plus that is the 'latest' version. So that jason site is top notch. He's created the packages for the 2.2, php 5.2.4, mysql 5.0.46. That's a great find there.
I was on a roll this morning and updated them all including the kernel . Took no more than 3 minutes to do the lot!
One gotcha - upgrading mysql blanked out the root password. That's the only post upgrade thing I had to sort out.
Glad you got it all sorted.
It is indeed a very good repo because as you say 2.0.5x is the latest package you can get using normal Yum repos.
Hail the mighty Mr Litka!
Will remember the mysql pass blanking when I upgrade mysql to the latest version later tonite.thanks for the tip
Agreed on the resource usage. Ive noticed my server stats looking significantly lower since that update.
Going to yum update the kernel and some other stuff tonite as well I think while Im on a roll!
New RPMs at jasonlitka.com
[edited by: Frank_Rizzo at 4:46 pm (utc) on Sep. 12, 2007]
I upgraded shortly after my last post..
and have nothing but good things to say about the new apache.
