Hey all,
I'm having a little bit of a weird issue on my web host. I was just
wondering if anyone's seen anything like this before.
The problem is that you can't seem to restart apache via the stock init
script that comes with apache:
[root at beta:~] #service httpd restart
Stopping httpd: [FAILED]
Starting httpd: [Mon Mar 03 11:21:14 2014] [warn] module php5_module is
already loaded, skipping
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address
0.0.0.0:80<http://0.0.0.0/>
no listening sockets available, shutting down
Unable to open logs
[FAILED]
[root at beta:~] #
IT complains that apache can't restart because apache is already listening.
So what you have to do in this case is kill it like so:
[root at beta:~] #pgrep httpd
12322
22405
22505
22506
22507
22508
22509
22510
22511
22512
[root at beta:~] #
[root at beta:~] #pkill httpd
And repeat as necessary until you can achieve this:
[root at beta:~] #pgrep httpd
[root at beta:~] #
It's a real pain with it being the way it is, because this makes it
impossible for puppet to manage this service. I'm mainly just tired of
seeing errors in the reports about this! :)
So whaddya think? Have you ever seen this problem before and do you know
how to solve this issue?
Thanks,
Tim
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
On Mon, Mar 3, 2014 at 3:28 PM, Tim Dunphy <bluethundr at gmail.com> wrote:> Hey all, > > I'm having a little bit of a weird issue on my web host. I was just > wondering if anyone's seen anything like this before. > > The problem is that you can't seem to restart apache via the stock init > script that comes with apache: > > [root at beta:~] #service httpd restart > Stopping httpd: [FAILED]That's not normal. It should say [OK] there.> So what you have to do in this case is kill it like so: >It is supposed to be killing the pid found in /var/run/httpd/httpd.pid. Can you tell why that doesn't work? You might get a hint from: sh -x /etc/init.d/httpd restart -- Les Mikesell lesmikesell at gmail.com
On 03/03/2014 03:28 PM, Tim Dunphy wrote:> Hey all, > > I'm having a little bit of a weird issue on my web host. I was just > wondering if anyone's seen anything like this before. > > The problem is that you can't seem to restart apache via the stock init > script that comes with apache: > > [root at beta:~] #service httpd restart > Stopping httpd: [FAILED] > Starting httpd: [Mon Mar 03 11:21:14 2014] [warn] module php5_module is > already loaded, skipping > (98)Address already in use: make_sock: could not bind to address [::]:80 > (98)Address already in use: make_sock: could not bind to address > 0.0.0.0:80<http://0.0.0.0/> > no listening sockets available, shutting down > Unable to open logs > [FAILED] > [root at beta:~] # > > IT complains that apache can't restart because apache is already listening. > > So what you have to do in this case is kill it like so: > > [root at beta:~] #pgrep httpd > 12322 > 22405 > 22505 > 22506 > 22507 > 22508 > 22509 > 22510 > 22511 > 22512 > [root at beta:~] # > > [root at beta:~] #pkill httpd > > > And repeat as necessary until you can achieve this: > > [root at beta:~] #pgrep httpd > [root at beta:~] # > > > It's a real pain with it being the way it is, because this makes it > impossible for puppet to manage this service. I'm mainly just tired of > seeing errors in the reports about this! :) > > So whaddya think? Have you ever seen this problem before and do you know > how to solve this issue? > > Thanks, > Tim >Are you sure all the instances were started by the stock initscript initially ... it sounds like something is killing or creating apache instances that are in /var/run/httpd/ That normally happens if httpd is started manually by another script or user process rather than the one in /etc/init.d/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20140303/5c91b23f/attachment-0002.sig>