| Summary: | httpd fails to start | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | William Kenney <wilcal.int> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | ftg |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | 5beta1 | ||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | httpd failing to start in M5B1 | ||
|
Description
William Kenney
2014-11-01 20:49:10 CET
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
William Kenney
2014-11-02 18:15:00 CET
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) 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 =>
RESOLVED |