From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 Galeon/1.3.10 Description of problem: Scenario: Fedora Core 1 system running httpd with mod_ssl Testing repository is enabled in yum.conf yum update is run run on Thursday httpd and mod_ssl are updated to 2.0.48-1.1 /etc/httpd/conf/mod_ssl.conf had been modified to include a CA certificate, ca.crt /etc/httpd/conf/mod_ssl.conf.rpmnew is created, because configuration file had been modified httpd isn't restarted Log rotation starts at 4:02am on Sunday morning /etc/logrotate.d/httpd runs /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` httpd dies with [error] Init: Failed to load Crypto Device API ` �' at 4:02:06am Monitoring server notices port 443 down at 4:03:06am Monitoring server notices port 80 down at 4:06:36am Monitoring server sends out sms messages to admin's cell phone Admin is awaken by noisy phone Admin finds four servers httpd's have died, including httpd used for the web interface of the monitoring software Admin happens to be logged into monitoring server and starts httpd Admin racks his brain and reminds the web server's password and logs in Admin diffs ssl.conf and ssl.conf.rpmnew, moves ssl.conf.rpmnew over ssl.conf, edits ssl.conf to uncomment ca.crt line and starts httpd Admin gets dressed, drives to work, and fixes httpd on other two servers This scenario just happened to me. I am not sure of the proper fix for it. One thing that I think would have helped would have been /etc/logrotate.d/httpd having actually restarted httpd instead of kill -HUP. I say this since without overwriting ssl.conf with ssl.conf.rpmnew httpd seems to start with service httpd start. Version-Release number of selected component (if applicable): httpd-2.0.48-1.1 How reproducible: Always Steps to Reproduce: 1. Update to httpd and mod_ssl 2. Do not restart httpd 3. Let log rotation happen on Sunday Actual Results: Crash Expected Results: No crash Additional info:
Thanks for the report, I can reproduce a crash here.
It was a rather nasty problem in mod_ssl. An upgrade from 2.0.47-10 to 2.0.48-1.2 will not suffer from this problem, though that's too late for you, of course. Thanks a lot for the report.
Fix in the httpd-2.0.48-1.2 update. Thanks for the report.