Bug 751591
Summary: | httpd should start up after network filesystems | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Edward Z. Yang <ezyang> |
Component: | httpd | Assignee: | Jan Kaluža <jkaluza> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | edwin.huffstutler, elliott.forney, jkaluza, jorton, mads, ngaywood, pahan |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | httpd-2.2.22-2.fc16 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-04-01 22:56:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Edward Z. Yang
2011-11-06 01:01:54 UTC
This is easier to do in the httpd systemd'ified world in the network filesystem packaging. In F15 you have to modify httpd.init because those knobs don't work. See also: https://scripts.mit.edu:444/trac/ticket/247 Thanks for the report. It looks like it should be sufficient to add "nfs-service.service" to the After: line for httpd.service, w.r.t. NFS, have you tested that? What's the name of the OpenAFS service, I don't think that's in Fedora? Yes. Alternatively, you can add Before and WantedBy to NFS's systemd package. It depends on which package you think should manage the dependency. OpenAFS is not in Fedora, so we have to do it this way. *** Bug 750595 has been marked as a duplicate of this bug. *** I don't see nfs-service.service Isn't the right thing "After=remote-fs.target" just like user sessions? Oh, I didn't actually check what NFS's systemd name is. I'm not sure which of these service files corresponds to the client: http://koji.fedoraproject.org/koji/rpminfo?rpmID=2754200 netfs.service is the NFS client service. It sounds to me like remote-fs.target is what we want... although I'm not certain. The problem is that netfs and httpd are both legacy /etc/init.d scripts in Fedora 15. How do you tell httpd.service to start after remote-fs.target or netfs.service when there is no unit file in /lib/systemd/system? Let me know if anyone would like me to test potential solutions, we have a machine that is affected by this. As I mentioned earlier, in F15, pre-systemd world, you need to edit the .init script; they have a special INIT INFO stanza, and you can modify 'Required-Start' in httpd.init to depend on all of the things you may need. But this isn't so good for the general Fedora environment, because Apache really shouldn't have to know about NFS. Things get better post systemd, so it might be more reasonable just to WONTFIX this for F15. Sorry, I didn't see your earlier post. I guess the mix of systems is what confuses me. I believe this worked fine in Fedora 14... does it work in Fedora 16? I presume these are all systemified in Fedora 16? I respectfully disagree that this should be closed as WONTFIX. Your argument is equivalent to saying "apache shouldn't have to know about ext4 so it is OK to start it before ext4 filesystems are mounted." Apache should not be started until ALL filesystems are mounted/mountable. Otherwise, it should block until they are. Either way something needs to change. My /etc/init.d/httpd already has the following in it: # Required-Start: $local_fs $remote_fs $network $named Are you sure systemd honors these? The problem is that NFS doesn't register itself as a remote_fs. So these don't work. I don't know how to do this using SysV stanzas; if we can find a way to do that, that would be ideal. Note we can do this for later versions of Fedora, so adding a remote_fs.target dependency is the right way to go. It looks like NFS in Fedora 17 doesn't register itself as a remote_fs either. Oops! We tested, and adding remote-fs.target to WantedBy in the Install does the right thing for ~all applications, including SysV scripts. We should do this for all versions of Fedora. Ok, I can't say I fully understood the WantedBy documentation, but it looks to me that with WantedBy=remote-fs.target, you can't run httpd without having remote-fs.target disabled. Even when you have remote-fs.target disabled, it gets enabled because httpd would need it. I'm not sure if this dependency is valid or not. I checked how other services do it, and it looks they simply define this: After= .... remote-fs.target Does it still work properly if you add remote-fs.target into After: definition? Yes. My httpd startup problem in F16 (with nfs+autofs documentroot) is fixed by adding After=remote-fs.target in the httpd service file. In fact I used this for a few other things with same systemd kind of bug (mythtv, mrtg, ...) I pinged systemd-devel on this issue. I think the semantics are slightly different depending on whether something is a target or a service. If I understood the systemd-devel thread, we should probably use After. I will commit it to rawhide, so it should be added into F16 on next update. What you want is After, such that httpd starts after remote-fs.target whether remote-fs.target is enabled or not. This is still an issue for me in F16. httpd-2.2.21-1.fc16.x86_64 There is no update in updates-testing. httpd-2.2.22-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/httpd-2.2.22-2.fc16 Package httpd-2.2.22-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing httpd-2.2.22-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3001/httpd-2.2.22-2.fc16 then log in and leave karma (feedback). httpd-2.2.22-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |