Has anyone noticed that when using NameVirtualHost's in apache that the service httpd restart command is broken?
Also it seems system-config-bind has glitches too.
Can someone confirm these? Hope its not just me...![]()
Has anyone noticed that when using NameVirtualHost's in apache that the service httpd restart command is broken?
Also it seems system-config-bind has glitches too.
Can someone confirm these? Hope its not just me...![]()
I've been in worse situations than this, but I can't seem to recall them... :eek:
I can confirm I have something bad going on, but it's long before virtualhosts. However I believe it's because I changed this server's name. Check your error log, do you have the same?
[Fri Jul 03 07:01:55 2009] [error] avahi_entry_group_add_service_strlst("localhost") failed: Invalid host name
[Fri Jul 03 07:01:55 2009] [error] avahi_entry_group_add_service_strlst("localhost") failed: Invalid host name
I've only taken it as far as:
lsof -i tcp:80
netstat -lp | grep -w LISTEN
nmap 127.0.0.1
and edited /etc/hosts, /etc/hosts.conf,
With any luck I've reminded you of something or tossed a command to help troubleshoot.
You MIGHT have a bad configuration option or something. I remember when I had a bad one I had to fix it before I could start or restart httpd.
Intel Core 2 Quad Q8400 CPU (2.66 GHz)
3gb RAM
500GB HD
Debian Lenny x86_64 & Windows 7 Ultimate x64
NVIDIA GeForce 9800 GTX+ Superclocked - Fattypack
Second(Server) PC:
512mb RAM
80gb TiVO HD(Lololol, took it from TiVO, old one broke)
PC-BSD 7.1.1 x86
Ossom router decked out with DD-WRT as a bridge providing net
Sign the Online Petition to bring Crysis 2 to Linux/Mac!
Configuration isn't bad in my case, If i wanted to restart the httpd service I have to use lsof -i tcp:80 and then kill all the processes in use.
Using service httpd restart is not killing the service off and therefore when it starts the service again it fails.
You can use apachectl -S to check your configuration.
As for an avahi issue not finding localhost, look at:
/etc/hosts
/etc/host.conf
/etc/resolv.conf
Also check you SELinux and Firewall settings.
I've been in worse situations than this, but I can't seem to recall them... :eek:
Thanks. I must have been drinking early Friday, after some swearing I finially realised this:
cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4Yeah I swear it wasn't there Friday.
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
My second problem was a broken symbolic link. /etc/httpd/run points to /var/run/httpd (default pid location from httpd.conf). You might want to check yours to be sure. Also look at /etc/init.d/httpd for:
# Path to the apachectl script, server binary, and short-form for messages.besure those paths exist.
apachectl=/usr/sbin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
prog=httpd
pidfile=${PIDFILE-/var/run/httpd/httpd.pid}
lockfile=${LOCKFILE-/var/lock/subsys/httpd}
RETVAL=0
for now I'm going for a drink and will create a virutalhost later. Maybe I can kick something up for you.
Last edited by beaker_; 5th July 2009 at 05:44 PM.
Just did the F10 -> F11 update within this week and the previously good Apache config didn't work in F11. Since I have nothing special in that config I just removed the config-file and re-installed Apache to get it running.
My httpd wasn't starting at all so no restart possible.
I copied my httpd.conf file and did a clean install of Fedora 11, it all works for me. What does /var/log/messages and /var/log/httpd/error_log say when you try to restart?
Registered linux user: #475337
Never underestimate someone with source code, a text editor, and the willingness to completely hose their system.
If the question was for me then here's the answer.
It complained about one of the lines in config and since I have made some minor trials with it I thought best to restore to default. All is well now
This is the old right hand not knowing what the left is doing after an upgrade
Solution:
The script that 'service' runs is /etc/rc.d/rc.init/httpd
In that script, there is a line that says pidfile=${PIDFILE-/var/run/httpd/httpd.pid}.
In Fedora 9, that line is pidfile=${PIDFILE-/var/run/httpd.pid}
Change your script to match the Fedora 9 line and that should solve the restart problem.
This solved a similar problem that I had. Someone tried changing the PID line in /etc/httpd/conf/httpd.conf to /run/httpd/httpd.pid, but it didn't work for them.
I have a similar problem. "service" and "system-config-services" are confused about
the status of httpd.
They say it is stopped, or dead, while it is running just fine. Consequently you can't stop, start, restart httpd from service or system-config-services.
The problem seems to be that httpd.pid is in the wrong place.
It is now in /var/run/httpd.pid, as opposed to /var/run/httpd/httpd.pid, where it was
on my system until yesterday.
If I copy httpd.pid to the httpd/ directory, "service" is fine. That is, until httpd starts again
for whatever reason (boot, restart with "service", restart with apachectl, you name it). Then the
same situation happens.
My /etc/init.d/httpd file says:
# Path to the apachectl script, server binary, and short-form for messages.
apachectl=/usr/sbin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
prog=httpd
pidfile=${PIDFILE-/var/run/httpd/httpd.pid}
lockfile=${LOCKFILE-/var/lock/subsys/httpd}
RETVAL=0
apache conf file /etc/httpd/conf/httpd.conf says:
#
# PidFile: The file in which the server should record its process
# identification number when it starts.
#
PidFile run/httpd/httpd.pid
How many more places does this path need to be configured?
And, more interestingly, where are those places?
Any Ideas where to look?
Bernd
Well after giving this thread some time to 'brew', its actually pointed me in the right direction (and mit turns out to be a configuration issue after all).
The /etc/httpd/conf/httpd.conf file was pointing the pid file to the wrong place.
So for you guys out there with this issue check the pid file path in the follwoing files.
- /etc/httpd/conf/httpd.conf
- /etc/init.d/httpd
- /etc/sysconfig/httpd
I've been in worse situations than this, but I can't seem to recall them... :eek: