Description of problem: httpd does not start as a service (returns FAILED). However, httpd will start when invoked directly from the command line. Version-Release number of selected component (if applicable): Fedora 13 (recent upgrade from Fedora 12, httpd worked fine in Fedora 12) httpd-2.2.16-1.fc13 (x86_64) How reproducible: always fails to start as a service always starts properly when invoked directly from command line Steps to Reproduce: 1. # service httpd start 2. Starting httpd: [FAILED] Actual results: Starting httpd: [FAILED] Expected results: Starting httpd: [ OK ] Additional info: # httpd (works - httpd starts properly when invoked at cmd line) # service httpd status httpd (pid 22366) is running... httpd worked fine for me on Fedora 12; recently upgraded to Fedora 13 using preupgrade
This is probably an SELinux-related failure. I suggest you # touch /.autorelabel # reboot to make sure everything is labelled correctly after your upgrade. If it still fails, check your audit logs. # ausearch -ts today -x httpd
Thanks for the quick response. I did the relabel, but that didn't fix it (same symptoms as above). The audit logs don't show anything # ausearch -ts today -x httpd <no matches> However I noticed something else. I'm using mod_ssl with the builtin terminal-based pass-phrase input (ie, I normally get a pass phrase request when I start httpd). When I turn off mod_ssl, then httpd starts properly as a service. That is, # mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.backup # service httpd start Starting httpd: [ OK ] and when I turn mod_ssl back on, httpd no-longer starts properly: # mv /etc/httpd/conf.d/ssl.conf.backup /etc/httpd/conf.d/ssl.conf # service httpd restart Stopping httpd: [ OK ] Starting httpd: [FAILED]
Check the error log for details then, /var/log/httpd/error_log.
OK, well in the failure case I get: /var/log/httpd/error_log: [Tue Aug 17 08:05:57 2010] [notice] SELinux policy enabled; httpd running as con text unconfined_u:system_r:httpd_t:s0 [Tue Aug 17 08:05:57 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin /suexec) [Tue Aug 17 08:05:57 2010] [notice] SSL FIPS mode disabled and /var/log/httpd/ssl_error_log: [Tue Aug 17 08:05:57 2010] [error] Init: Unable to read pass phrase [Hint: key i ntroduced or changed before restart?] [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218529960 error:0D0680A8:a sn1 encoding routines:ASN1_CHECK_TLEN:wrong tag [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218640442 error:0D08303A:a sn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218529960 error:0D0680A8:a sn1 encoding routines:ASN1_CHECK_TLEN:wrong tag [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 67710980 error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag [Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error and in the success case (ie, started directly from cmd line) I get: /var/log/httpd/error_log: [Tue Aug 17 08:06:06 2010] [notice] SELinux policy enabled; httpd running as context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [Tue Aug 17 08:06:06 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Aug 17 08:06:06 2010] [notice] SSL FIPS mode disabled [Tue Aug 17 08:06:08 2010] [notice] Digest: generating secret for digest authentication ... [Tue Aug 17 08:06:08 2010] [notice] Digest: done [Tue Aug 17 08:06:08 2010] [notice] SSL FIPS mode disabled [Tue Aug 17 08:06:08 2010] [notice] Apache/2.2.16 (Unix) DAV/2 PHP/5.3.2 mod_ssl/2.2.16 OpenSSL/1.0.0a-fips configured -- resuming normal operations and /var/log/httpd/ssl_error_log: [Tue Aug 17 08:06:08 2010] [warn] RSA server certificate CommonName (CN) `Server' does NOT match server name!? [Tue Aug 17 08:06:08 2010] [warn] RSA server certificate CommonName (CN) `Server' does NOT match server name!?
The error message is surprising. Have you configured an SSL cert with a private key which requires a passphrase to decrypt? If so, does running "setsebool httpd_tty_comm=1" make a difference? If not, I'd suspect that SELinux is causing the SSL cert/key to be unreadable by httpd. SELinux is only activated when you start httpd from the init script, not directly. But it's surprising that audit failures don't show if this is the case. ls -lZ output on the certs/keys? Please attach complete mod_ssl configuration (/etc/httpd/conf.d/ssl.conf)
Yes, I use mod_ssl with a private key with passphrase (ie, using the SSLPassPhraseDialog builtin directive in ssl.conf) OK, running "setsebool httpd_tty_comm=1" fixes this for me. I can now use "service httpd start" and it starts httpd (and prompts for the SSL password). Many thanks. Do you still want the mod_ssl config and keys/certs list?
I'm kind of surprised by this since I thought that httpd_tty_comm was still set by default. Is it expected/desired that httpd_tty_comm is unset by default, Dan? In the past I had developed a separate program "htsslpass" which could be allowed terminal access and was used by httpd by default to read the from /dev/tty (effectively as a "proxy"). This can be resurrected if it is deemed necessary to disallow httpd terminal access by default.
It was on in F12 and off in F13. I will turn it back on in F14. It is on in RHEL6.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.