Apache httpd restart gets NamedVirtualHost error

23 posts / 0 new
Last post
#1 Fri, 01/31/2014 - 11:00
calderwood
calderwood's picture

Apache httpd restart gets NamedVirtualHost error

On GPL version, if I restart httpd I get an error. I found some similar errors on the support site but no fixes. The error is:

#/etc/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: [Fri Jan 31 11:33:49 2014] [error] VirtualHost _default_:443 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results

I see that the VirtualHost default:443 is in the conf but if I delete or change to VirtualHost default:443 apache fails.

Any advice as to what to look at. I run about 6 SSL certificates on the site and they all work.

Sat, 02/01/2014 - 04:01
Locutus

Apache's "default" SSL vhost is not really supposed to be used with Virtualmin, since it takes its document from /var/www, which is not supported by Virtualmin.

How did you set up / enable that SSL site? You should create your sites through the Virtualmin interface and turn on the "SSL Website" feature there, then Virtualmin will create a correct vhost entry for Apache on port 443. The default SSL site should be disabled.

Sun, 02/02/2014 - 13:16
calderwood
calderwood's picture

This site has been stable for a year. This just started. In fact the site went down about 5 minutes ago. To add SSL I go to the virtual server, select manage SSL and add the cert and CA.

The crash that just happened, I tried to restart httpd, but ended up doing a full reboot, and again the two additional IPs and all IP6 did not load on reboot and I had to manually add.

[error] VirtualHost _default_:443 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results

David Calderwood - Euro-Pacific Digital Media

Sun, 02/02/2014 - 13:36
Locutus

Well all I can say is that the default SSL site should not be enabled, since it indeed has a "*" as IP, and has its directory root in /var/www (normally, by default). Virtualmin configures its SSL sites with the actual server IP and uses /home/DOMAIN/public_html as directory root, as it is required.

To be able to say anything further, I'd probably need to take a look at your system directly, because otherwise it'd be too much poking in the dark on my end.

Mon, 02/03/2014 - 12:15 (Reply to #4)
calderwood
calderwood's picture

I don't believe that it is enabled. Where would that setting be in the CP?

I don't see anything for default SSL settings in Virtualmin or Webmin.

All my SSL certs are in the /home/DOMAIN/ for the related domain.

David Calderwood - Euro-Pacific Digital Media

Mon, 02/03/2014 - 12:36 (Reply to #5)
calderwood
calderwood's picture

I just checked the settings at Virtual Server Options For default:443 The SSL is set to NONE - same with the SSL settings for default server (any)

David Calderwood - Euro-Pacific Digital Media

Mon, 02/03/2014 - 12:36 (Reply to #6)
calderwood
calderwood's picture

I just checked the settings at Virtual Server Options For default:443 The SSL is set to NONE - same with the SSL settings for default server (any)

David Calderwood - Euro-Pacific Digital Media

Sun, 02/02/2014 - 13:40
calderwood
calderwood's picture

Here are the logs when apache failed:

[Sun Feb 02 12:20:38 2014] [warn] mod_fcgid: cleanup zombie process 28202
[Sun Feb 02 13:23:41 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sun Feb 02 13:23:41 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sun Feb 02 13:23:42 2014] [notice] Digest: generating secret for digest authentication ...
[Sun Feb 02 13:23:42 2014] [notice] Digest: done
[Sun Feb 02 13:23:42 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sun Feb 02 13:23:42 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_fcgid/2.3.9 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips SVN/1.6.11 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0
[Sun Feb 02 13:25:19 2014] [notice] caught SIGTERM, shutting down
[Sun Feb 02 13:25:27 2014] [error] FastCGI process 17930 still did not exit, terminating forcefully
[Sun Feb 02 13:26:52 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sun Feb 02 13:26:52 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sun Feb 02 13:26:52 2014] [notice] Digest: generating secret for digest authentication ...
[Sun Feb 02 13:26:52 2014] [notice] Digest: done
[Sun Feb 02 13:26:53 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sun Feb 02 13:26:53 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_fcgid/2.3.9 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips SVN/1.6.11 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
PHP Warning:  Module 'mcrypt' already loaded in Unknown on line 0

In the webmin miniserver.error logs I have this:

Error: Failed to connect to localhost:10001 : Connection refused
sh: -c: line 0: syntax error near unexpected token `newline'
sh: -c: line 0: `(hostname) 2>'
Failed to initialize SSL connection
Failed to initialize SSL connection
Failed to initialize SSL connection
find \/usr\/share\/perl5 -name .packlist -print
find \/usr\/local\/share\/perl5 -name .packlist -print
find: `/usr/local/share/perl5': No such file or directory
find \/usr\/local\/lib64\/perl5 -name .packlist -print
find: `/usr/local/lib64/perl5': No such file or directory
find \/usr\/share\/perl5\/vendor_perl -name .packlist -print
find \/usr\/share\/perl5 -name .packlist -print
Error: Starting httpd: [Sun Feb 02 13:21:33 2014] [error] VirtualHost _default_:443 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results
(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
no listening sockets available, shutting down
Unable to open logs
[FAILED]

[02/Feb/2014:13:27:07 -0500] miniserv.pl started

David Calderwood - Euro-Pacific Digital Media

Mon, 02/03/2014 - 13:46
Locutus

The problem is not an active or inactive SSL cert, but the fact that the Apache's default vhost on port 443 is active. Its configuration has the "*:443" in it which probably triggers your error. You should just disable that vhost, and move its stuff elsewhere if you actually use it (which I doubt, since as I said its document root is usually in /var/www, which is not supported by Virtualmin).

See if you have the "a2dissite" command in your system, otherwise check the directory /etc/apache2/sites-enabled which contains softlinks to the files in sites-available and delete the problematic one.

Mon, 02/03/2014 - 16:49
calderwood
calderwood's picture

I am running CentOS6 and so my apache is /etc/httpd/conf.d/ but there is no file sites-enabled - I searched through the ssl.conf file which includes the line:

VirtualHost _default_:443

But if I delete of cancel out it crashes apache.

Something somewhere in Virtualmin or Webmin must be pointing to the ssl.conf but I cannot find what. The ssl.conf is from April 2013.

David Calderwood - Euro-Pacific Digital Media

Mon, 02/03/2014 - 18:17
andreychek

Apache uses the ssl.conf file, and every other .conf file in that directory, whenever it starts up. It sounds like there's some settings in there that are causing problems though.

In your case, you'd want to make sure that you don't see any VirtualHost or NameVirtualHost entries that include an "*" in them. For example, you don't want *:443, you always want it to use "x.x.x.x:443", where x.x.x.x is your server's IP address.

-Eric

Mon, 02/03/2014 - 18:51 (Reply to #11)
calderwood
calderwood's picture

Thanks Eric.

I blocked out the entire VirtualHost default block in the SSL.conf and that has got rid of the *:443 error, but now I am getting a warning: [warn] NameVirtualHost *:0 has no VirtualHosts I've searched through the conf files but don't see this.

Also, in the SSL.CONF there is one other *.443 that I'm not sure if I should block out:

LoadModule ssl_module modules/mod_ssl.so
#
# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen *:443

David Calderwood - Euro-Pacific Digital Media

Tue, 02/04/2014 - 02:17
Locutus

Right, I keep forgetting that CentOS does things differently in this regard. :) Eric can help, he's the CentOS guy here. ;)

Thu, 02/06/2014 - 17:34
calderwood
calderwood's picture

I run multiple SSL on the same IPs. This was not a problem until the last few weeks. If you go to a site with 10000 or 20000 port, this is what I get:

You attempted to reach shoots.com, but instead you actually reached a server identifying itself as www.epdigital.biz. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of shoots.com.

I went to https://shoots.com:20000/ which has a SSL and is on its own IP address, but the cert that shows up is epdigital.biz - if I go to https://shoots.com the correct cert shows up. I know this is all related somewhere.

Ideas? Thoughts?

David Calderwood - Euro-Pacific Digital Media

Sun, 02/09/2014 - 21:23
rapidwebs

im pretty sure that under the Virtualmin Configuration page, there is a setting under the "apache" section, where you can either define to let users share your companies ssl cert (when landing on the webmin or usermin pages),

or in your case, you would want each site to use their own cert, in order to prevent this conflict-

i'm pretty sure it's intended use scenario would include redirecting to your companies domain, where you have a working and paid for SSL cert. this would ensures that all users logging into Webmin, or Usermin, can verify their connection respectively to the back-end without needing to purchase their own certificate from an authenticated vendor.

Sun, 02/09/2014 - 21:25
rapidwebs

note: i too have this problem (cron complains with the error in the original post)

however, each time i CHANGED the setting in ports.conf, it seemed that something was reverting or injecting the problem line,

i couldent' get the issue to easily go away, but continued to ignore it because it did not seem to cripple anything

Thu, 03/06/2014 - 07:32
calderwood
calderwood's picture

Well, it has been 4 weeks of uneventful operation, then out of the blue yesterday at mid-day apache stops. There is nothing in the logs other than 100's of zombie process warnings, but in the past I've been told on these forums that they are not an issue and to ignore.

I attempt restart apache and get this error:

Error: Starting httpd: [Wed Mar 05 13:32:46 2014] [warn] NameVirtualHost *:0 has no VirtualHosts
(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
no listening sockets available, shutting down
Unable to open logs
[FAILED]

I am unable to restart. All other services are working normally - email, control panel, etc.

Next I re-boot the server and apache starts up, however, only one IP address loads in the Network Interface on eth0. The Network Config includes the other two IPs in eth0:1 and eth0:2, but they do not load and I have to manually add them. The IPs are listed in Host Addresses.

Is this anything to do with OpenVZ?

David Calderwood - Euro-Pacific Digital Media

Thu, 03/06/2014 - 07:36
Locutus

I don't know immediately about the eth issue, but the "mid-day Apache stop" can well have been an OpenVZ issue. When you run into resource limitations, OpenVZ tends to just randomly kill processes. You can check the file /proc/user_beancounters then for values >0 in the "Fail" column.

Thu, 03/06/2014 - 09:50
calderwood
calderwood's picture

Not seeing anything above zero, but would these numbers change after a reboot? This is almost 24 hours later.

Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
10086860:  kmemsize                 77024277             89847301  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                    0  9223372036854775807  9223372036854775807                    0
            privvmpages                836908               882073              1572864              1572864                    0
            shmpages                     1206                 1206  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                       172                  184                32567                32567                    0
            physpages                  602222               639704  9223372036854775807  9223372036854775807                    0
            vmguarpages                     0                    0               786432  9223372036854775807                    0
            oomguarpages               602223               639705  9223372036854775807  9223372036854775807                    0
            numtcpsock                     53                   66  9223372036854775807  9223372036854775807                    0
            numflock                       76                   79  9223372036854775807  9223372036854775807                    0
            numpty                          1                    1                  255                  255                    0
            numsiginfo                      1                    2                 1024                 1024                    0
            tcpsndbuf                 1652640              2696768  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                  868352              1081344  9223372036854775807  9223372036854775807                    0
            othersockbuf               332000               518368  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                 9792  9223372036854775807  9223372036854775807                    0
            numothersock                  227                  230  9223372036854775807  9223372036854775807                    0
            dcachesize                3040663              3085735  9223372036854775807  9223372036854775807                    0
            numfile                     27470                27945  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      41                   41  9223372036854775807  9223372036854775807                    0

David Calderwood - Euro-Pacific Digital Media

Thu, 03/06/2014 - 10:15
Locutus

Yes, the failcount would only be meaningful right after you ran into problems. The values are reset when you reboot the server.

Thu, 07/10/2014 - 16:03
calderwood
calderwood's picture

I have had Apache stop working a couple of times a day. Same error message if I try to restart apache:

[Thu Jul 10 15:19:07 2014] [notice] child pid 1725 exit signal Aborted (6)
[Thu Jul 10 15:23:45 2014] [warn] mod_fcgid: cleanup zombie process 15683
[Thu Jul 10 15:26:55 2014] [error] mod_fcgid: fcgid process manager died, restarting the server
[Thu Jul 10 15:26:57 2014] [notice] SIGHUP received.  Attempting to restart
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:50e:3150::2:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:50e:3150::5:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:50e:3150::b:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:50e:3150::c:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:50e:3150::f:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:50e:3150::f:443 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:050e:3150:0000:0000:0000:21:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:050e:3150:0000:0000:0000:22:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost 2607:f208:050e:3150:0000:0000:0000:23:80 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [warn] NameVirtualHost *:0 has no VirtualHosts
[Thu Jul 10 15:26:57 2014] [notice] Digest: generating secret for digest authentication ...
[Thu Jul 10 15:26:57 2014] [notice] Digest: done
[Thu Jul 10 15:26:57 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Thu Jul 10 15:26:57 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_fcgid/2.3.9 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips SVN/1.6.11 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations

Apache does NOT restart

Doing a manual restart - I get the same error messages and apache will not start. To get the service to strat I must go:

[root@ip-68-178-130-21 ~]# killall -9 httpd
[root@ip-68-178-130-21 ~]# service httpd start
Starting httpd: [Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:50e:3150::2:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:50e:3150::5:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:50e:3150::b:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:50e:3150::c:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:50e:3150::f:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:50e:3150::f:443 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:050e:3150:0000:0000:0000:21:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:050e:3150:0000:0000:0000:22:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost 2607:f208:050e:3150:0000:0000:0000:23:80 has no VirtualHosts
[Thu Jul 10 16:14:08 2014] [warn] NameVirtualHost *:0 has no VirtualHosts
                                                           [  OK  ]
[root@ip-68-178-130-21 ~]# service httpd status
httpd (pid  1806) is running...

Still get these warnings. Before the service failed I did notice that there were a lot of /usr/sbin/httpd commands with a memory size of about 450mb each. At one stage there were dozens, but the pid shows it as ended.

Andy I have included the beancounter that was captured after apache stopped and before I restarted.

Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
10086860:  kmemsize                 72831054             75282395  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                    0  9223372036854775807  9223372036854775807                    0
            privvmpages                480761               538398              1572864              1572864                    0
            shmpages                     1206                 1206  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                       145                  147                32567                32567                    0
            physpages                  222736               279237  9223372036854775807  9223372036854775807                    0
            vmguarpages                     0                    0               786432  9223372036854775807                    0
            oomguarpages               222737               279238  9223372036854775807  9223372036854775807                    0
            numtcpsock                     52                   55  9223372036854775807  9223372036854775807                    0
            numflock                      115                  117  9223372036854775807  9223372036854775807                    0
            numpty                          1                    1                  255                  255                    0
            numsiginfo                      1                    1                 1024                 1024                    0
            tcpsndbuf                 2995104              3058816  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                  851968               901120  9223372036854775807  9223372036854775807                    0
            othersockbuf               302080               506880  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                 8480  9223372036854775807  9223372036854775807                    0
            numothersock                  169                  175  9223372036854775807  9223372036854775807                    0
            dcachesize                2647881              2730513  9223372036854775807  9223372036854775807                    0
            numfile                     22748                23421  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      41                   41  9223372036854775807  9223372036854775807                    0

David Calderwood - Euro-Pacific Digital Media

Thu, 07/10/2014 - 16:04
calderwood
calderwood's picture

Sorry Bump

David Calderwood - Euro-Pacific Digital Media

Fri, 07/11/2014 - 14:30
rapidwebs

about "could not bind 0.0.0.0:80":

use top or htop to see if Apache is actually dead of not. sometimes it it will restart, get updated, etc, and it's PID file will not get updated. this makes virtualmin think that Apache is dead, when it is indeed alive. I didn't see anything in particular within regard to your log files, that make me think apache actually errored out.

the only lines I seen related to Apache having quit, was it catching SIGTERM, which might be related to you restarting apache, or maybe the OOM task manager has killed it.

How much Memory does your system have? do you have any Cron scripts that consume a large amount of memory? do you use clamscan or clamd?

about your zombie processes:

use top or htop to find out what is in the zombie state. if it is Apache Processes, their might be something that is not configured properly. I could be wrong, but this might cause problems with Apache, and how it calculates it's worker pool size and resource limts.

if the zombie processes are php-cgi processes, than mod_fcgid is not properly configured to clean up dead workers. it might not be a problem in theory (remember: you are using a container and things are simulated, which can often cause things to have unexpected results), but I would argue that If fcgid is not cleaning up zombie processes properly, it might not be managing it's resources properly either.

properly configured, mod_fcgid should spawn php-cgi processes on demand as needed, but it should be set to max out somewhere, and be set to properly clean up these processes depending on error, timeout, and period of time in the busy state. in virtualmin, you set only the worker pool size.

you must take a look at fcgid.conf and configure this to suit your servers demands, by setting things like timeouts and maximum processes limits. per class = per website (or per user).

left improperly configured, mod_fcgid could quickly consume all your resources, and OpenVZ and the OOM Task Manager will kill things at random (even Apache itself).

however, when it is configured right, you can have each site always leave one worker pool running, but max out at some sort of reasonable limit. when configured right, mod_fcgid will kill it's zombies in a timley manner.

with all this said, make sure that Apache is actually dead. it could just be reported dead in error. like I said, next time this happens, check using top or htop. if it IS being killed, you might want to look into "monit". this is a very easy to configure process monitor, which will bring up apache as soon as it goes down, and can even kill or restart apache if it starts to consume too much resources, and spins out of control.

Topic locked