Forums

Resolved
0 votes
So about 6 months ago I let my subscription to Roundcube laps, shortly after I realized that the web server service was no longer running. I assumed there was something tying the paid service to the web server and when the subscription lapsed it disabled the web server. I removed Roundcube through the Marketplace uninstall feature, but the web server still would not load. I left it as I no longer needed the web server running anyway and I would solve the problem later. Fast forward to tonight, I renewed my subscription to Roundcube and re-installed it. But, low and behold, the web server still will not start. From the WebUI it simply refreshes the page and shows the service status as "stopped".

Output of
systemctl status httpd.service

● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-04-01 21:50:59 CDT; 10s ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 31265 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Process: 31259 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 31259 (code=exited, status=1/FAILURE)

Apr 01 21:50:59 destiny.removed-domain.com systemd[1]: Starting The Apache HTTP Server...
Apr 01 21:50:59 destiny.removed-domain.com systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Apr 01 21:50:59 destiny.removed-domain.com kill[31265]: kill: cannot find process ""
Apr 01 21:50:59 destiny.removed-domain.com systemd[1]: httpd.service: control process exited, code=exited status=1
Apr 01 21:50:59 destiny.removed-domain.com systemd[1]: Failed to start The Apache HTTP Server.
Apr 01 21:50:59 destiny.removed-domain.com systemd[1]: Unit httpd.service entered failed state.
Apr 01 21:50:59 destiny.removed-domain.com systemd[1]: httpd.service failed.


Output of
journalctl -xe

Apr 01 22:01:32 destiny.removed-domain.com arpwatch[1531]: bogon 169.254.154.195 00:24:73:ca:9a:c3
Apr 01 22:01:33 destiny.ebschfamily.com systemd[1]: Starting The Apache HTTP Server...
-- Subject: Unit httpd.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit httpd.service has begun starting up.
Apr 01 22:01:33 destiny.removed-domain.com systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Apr 01 22:01:33 destiny.removed-domain.com kill[4135]: kill: cannot find process ""
Apr 01 22:01:33 destiny.removed-domain.com systemd[1]: httpd.service: control process exited, code=exited status=1
Apr 01 22:01:33 destiny.removed-domain.com systemd[1]: Failed to start The Apache HTTP Server.
-- Subject: Unit httpd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit httpd.service has failed.
--
-- The result is failed.
Apr 01 22:01:33 destiny.removed-domain.com systemd[1]: Unit httpd.service entered failed state.
Apr 01 22:01:33 destiny.removed-domain.com systemd[1]: httpd.service failed.


I have not changed any of the Apache config files or have any other websites running at all, just need it for webmail. Any assistance would be appreciated.
Tuesday, April 02 2019, 03:04 AM
Share this post:
Responses (5)
  • Accepted Answer

    Thursday, April 04 2019, 07:51 AM - #Permalink
    Resolved
    0 votes
    If you already have a public facing web server then you will struggle with Let's Encrypt as it will not pass on the Let's Encrypt renewal transactions which set up another temporary webserver on your system and listen on port 80. If you use Proxypass, you should be able to use the external facing server's Let's Encrypt certificate for the traffic forwarded to Roundcube and Roundcube should be able to use the server's devault certificate. If you are replicating the Let's Encrypt structure on Roundcube and still running Let's Encrypt on the machine, you may have problems around renewal time. It depends on which machine triggers the renewal first and how quickly you copy your certificates across to the Roundcube machine.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 03 2019, 04:23 PM - #Permalink
    Resolved
    0 votes
    Well, you certainly had me going in the right direction. For some odd reason I could not get a single newly generated self-signed certificate to work. So, already having a public facing web server running on my network, hence why I don't use the web server on this machine, I cloned the
    /etc/letsencrypt
    directory from that server to this one and adjusted the Apache config to use those certs/keys etc. Also noticed while I was getting all this in place that the default web directory, which I just have a redirect file to point to /webmail was owned by the user:group root and not apache. After getting the new certs in place and fixing the directory permissions the web server started right up. For good measure I set my main web server to copy the new cert/key files over to this server whenever the LetsEncrypt renewal service runs.

    Thanks for the help!
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 03 2019, 07:18 AM - #Permalink
    Resolved
    0 votes
    So do the certificate and key exist:
    ls /etc/pki/tls/*/localhost.*
    I suspect it may be a permission issue, but the best way round is to sidestep it. Try installing the Web Server and Let's Encrypt. Create a Let's Encrypt certificate to cover your server (which can include your poweredbyclear.com domain). There is currently a bug and after the certificate gets created, you'll get an Oooops. Delete the file /etc/letsencrypt/live/README and the Oooops will go away. Then configure the default web server to use your Let's Encrypt certificate.

    Looking at the manifest, I think you have the Web Server already installed.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 03 2019, 12:45 AM - #Permalink
    Resolved
    0 votes
    Sorry, was so tired last night I completely forgot to check the logs. Here is the repeating error in the most recent file "error_log"
    [Mon Apr 01 22:06:42.295644 2019] [suexec:notice] [pid 6486] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
    [Mon Apr 01 22:06:42.296015 2019] [ssl:emerg] [pid 6486] AH02241: Init: Unable to read server certificate from file /etc/pki/tls/certs/localhost.crt
    [Mon Apr 01 22:06:42.296049 2019] [ssl:emerg] [pid 6486] SSL Library Error: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long
    [Mon Apr 01 22:06:42.296060 2019] [ssl:emerg] [pid 6486] AH02312: Fatal error initialising mod_ssl, exiting.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 02 2019, 10:44 AM - #Permalink
    Resolved
    0 votes
    Can you check the log files in /var/log/httpd and look for errors. in the past I found a problem that Apache would not create a log file for a vhost and fail to start. All that was needed was to make the log file exist with the "touch" command. I never properly toubleshooted it as I seem to remember it was for a vhost which no longer existed. I also seem to remember that I found the error by looking at the main httpd log files.
    The reply is currently minimized Show
Your Reply