After a successful install of ..... an update of the install resulted in httpd not starting. httpd did work before the update. [root@localhost wilcal]# service httpd start Redirecting to /bin/systemctl start httpd.service Job for httpd.service failed. See "systemctl status httpd.service" and "journalctl -xe" for details. [root@localhost wilcal]# ^C [root@localhost wilcal]# systemctl status httpd.service â httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: failed (Result: exit-code) since Sat 2014-11-01 12:22:23 PDT; 45s ago Process: 2195 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE) Main PID: 2195 (code=exited, status=1/FAILURE) Nov 01 12:22:23 localhost httpd[2195]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'S...is message Nov 01 12:22:23 localhost systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE Nov 01 12:22:23 localhost systemd[1]: Failed to start The Apache HTTP Server. Nov 01 12:22:23 localhost systemd[1]: Unit httpd.service entered failed state. Nov 01 12:22:23 localhost systemd[1]: httpd.service failed. Hint: Some lines were ellipsized, use -l to show in full. Reproducible: Steps to Reproduce:
For some reason httpd worked fine as a Vbox client but when I went to real hardware, then updated the install, httpd stopped working and I could not get it to start. Proftp works just fine.
Do you see anything in the logs in /var/log/httpd, or /var/log/messages or /var/log/syslog or the systemd journal (journalctl) that indicate what the problem is? You haven't provided any information that can be used to debug this.
Keywords: (none) => NEEDINFO
(In reply to David Walser from comment #2) > Do you see anything in the logs in /var/log/httpd, or /var/log/messages or > /var/log/syslog or the systemd journal (journalctl) that indicate what the > problem is? You haven't provided any information that can be used to debug > this. Thanks for the response David. I'm still work'n this one. This test install was on an x86-64 machine. I'm gonna try a HW install on an i586 machine later today and see if it does the same thing. For now lemme just tinkerwith it. Any help, like look'n at /var/log/httpd /var/log/messages or /var/log/syslog, is helpful.
Created attachment 5556 [details] httpd failing to start in M5B1 Looking at this again this morning I'm finding that httpd is failing on all of my M5 test platforms. I have attached httpd_fail.txt to this bug with copys of what I think is the the relevant text from service httpd start, /var/log/httpd/error_log, /var/log/messages and /var/log/syslog
Looking at this again this morning I'm finding that httpd is failing on all of my M5 test platforms. I have attached httpd_fail.txt to this bug with copys of what I think is the the relevant text from service httpd start, /var/log/httpd/error_log, /var/log/messages and /var/log/syslog
Whiteboard: (none) => 5beta1
Comment on attachment 5556 [details] httpd failing to start in M5B1 The only thing in that attachment that appears to say anything is the lines like: "[Sun Nov 02 07:25:18.808960 2014] [core:emerg] [pid 1183] (2)No such file or directory: AH00023: Couldn't create the rewrite-map mutex (file /run/httpd/rewrite-map.1183) AH00016: Configuration Failed" What is the output of "ls -ld /run/httpd" ?
(In reply to David Walser from comment #6) > What is the output of "ls -ld /run/httpd" ? [root@localhost wilcal]# ls -ld /run/httpd ls: cannot access /run/httpd: No such file or directory And indeed in /run there is no httpd anything. In this M4 workstation that is running httpd there is: /run/httpd/authdigest_shm.1459 /run/httpd/httpd.pid
Just for giggles, try "mkdir /run/httpd; chown apache:apache /run/httpd" and retest.
CC: (none) => ftg
We don't need any giggles, of course it'll work if /run/httpd exists. systemd-tmpfiles isn't working, and that's clearly the issue.
Keywords: NEEDINFO => (none)Assignee: bugsquad => mageia
Can you test: 1. stop apache 2. rm -rf /run/httpd 3. /usr/bin/systemd-tmpfiles --create 4. ls -ld /run/httpd This works fine for me here on Cauldron.
(In reply to David Walser from comment #9) > We don't need any giggles, of course it'll work if /run/httpd exists. > > systemd-tmpfiles isn't working, and that's clearly the issue. I wasn't aware that creation of /run/httpd was the responsibility of systemd-tmpfiles. The intent of the test was to see if, in trying to create /run/httpd/rewrite-map.1183, apache wasn't creating the needed directory structure itself, and whether it ought to be.
As apache is run by root at this stage (due to it needing to be root to get port 80) it may as well create the folder internally rather than rely on external stuff and/or packaging to do it for us, so IMO, apache itself could be fixed instead to do the necessary mkdir stuff.
(In reply to Colin Guthrie from comment #10) > Can you test: > > 1. stop apache > 2. rm -rf /run/httpd > 3. /usr/bin/systemd-tmpfiles --create > 4. ls -ld /run/httpd > > This works fine for me here on Cauldron. This is getting very interesting. Yes Colin, infact running through the process you described does get httpd going again, and it works just fine. But, it does not survive a reboot. Upon a reboot the /run/httpd directory is gone again and service httpd does not start.
(In reply to William Kenney from comment #13) > This is getting very interesting. Yes Colin, infact running through > the process you described does get httpd going again, and it works > just fine. But, it does not survive a reboot. Upon a reboot the > /run/httpd directory is gone again and service httpd does not start. After a fresh boot, what does the following command (run as root) say: systemctl status systemd-tmpfiles-setup.service
(In reply to Colin Guthrie from comment #14) > After a fresh boot, what does the following command (run as root) say: > > systemctl status systemd-tmpfiles-setup.service [root@localhost wilcal]# systemctl status systemd-tmpfiles-setup.service â systemd-tmpfiles-setup.service - Create Volatile Files and Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: inactive (dead) Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8)
I'm here for about another hour.
OK, so that looks like it's not even being tried at all (as it says "inactive (dead)"). Smells very much like there is some kind of early boot ordering cycle problems and this is just a symptom of it bubbling up. Please reboot with "systemd.log_level=7 systemd.log_target=journal" on the kernel command line and post the output of "journalctl -b" Thanks!
Note that both this and: https://bugs.mageia.org/show_bug.cgi?id=14436 seem to have occured both during the same update last week. The NFS mount thing has also been attributed historically to boot ordering sequence.
(In reply to Colin Guthrie from comment #17) > Please reboot with "systemd.log_level=7 systemd.log_target=journal" on the > kernel command line and post the output of "journalctl -b" Your gonna have to coach me on how to do that. I'm using GRUB2 on the system under test. Also I've got two Vbox M5 installs that are about a week old that don't exhibit this problem. Both the NFS and HTTPD thing surfaced at the same time on new M5 installs about Thursday last week.
I'm afraid I don't know anything about GRUB2 (I have avoided it like the plague). In older grub you just hit esc, then e for edit, then edited it and pressed return and then hit b to boot it.
(In reply to Colin Guthrie from comment #20) > I'm afraid I don't know anything about GRUB2 (I have avoided it like the > plague). In older grub you just hit esc, then e for edit, then edited it and > pressed return and then hit b to boot it. Thanks. I'll have to let you guys take this from here.
Hmm, this looks like a likely fix: http://cgit.freedesktop.org/systemd/systemd/commit/?id=919699ec301ea507edce4a619141ed22e789ac0d I'll apply it in my next build
Resolved in latest builds.
Resolved
Status: NEW => RESOLVEDResolution: (none) => FIXED