Apache fails to listen to IPv6 on boot -- restarting it helps

The global listen directives in /etc/apache2/ports.conf are:

Listen 80
Listen 443

The main config file ends with:

NameVirtualHost 46.4.181.243:80
NameVirtualHost 46.4.181.243:443

Interestingly, no mention of the IPv6 addresses yet... Well, "Listen" without address probably means "listen on everything available".

Or... is this maybe correct? Since I do not have more than one vhost that shares the same IPv6 address, but both of the test vhosts are reaching Apache through their individual IP, I suppose that's not a "name virtual host", but an "address virtual host" to Apache.

The two virtual servers in question have this in their vhost config file:

VirtualHost 46.4.181.243:80 (2a01:4f8:101:1ffc::1:20):80

EDIT: I replaced the square brackets around the IPv6 address with round brackets, cause the forum otherwise won't show the line.

That's for the "test7" one. The "test8" has "::1:21" respectively.

Argh! I actually already posted the virtualhost block, but the forum is hiding it for some reason. I'll try again to make it visible. :P

Edited it. Replaced [ with (, as to hide that "command" from the forum.

Also, please note that Apache does, with the exact same config, start up fine when I re-start it after system boot is complete! Only during boot, the startup produces the errors (which causes it to not listen on TCP6, the rest is okay).

So I'm guessing the config should be okay, but it's rather like the (additional, per-SSL-site) IPv6 addresses are not yet available during boot.

I edited post #2, which already had the virtualhost line, but seemingly the [ ] characters in it confused the forum software. So I replaced them with ( )... just saying so that you don't think there's an error in the file. :)

As for Ubuntu bug... it's possible. Though I'm wondering if anyone else is seeing this issue. Ubuntu is rather widespread, as is Apache, and Virtualmin hopefully too. :)

I'll see if there some way to instruct the init process to wait with the Apache start until all IPv6 addresses have been set.

It's definitely a race condition. The error messages Apache gives during boot are not always the same. Sometimes it fails for one of the two IPv6 IPs, sometimes for both.

My assumption is that the ifconfig command which gets launched in the /etc/network/interfaces file to add the IPs needs some time "in the background" (i.e. after the executable call returns) to actually bring up the addresses. When Apache starts launching before that is complete... bam.

I ended up doing something similar as you suggested. I added this in the "iface" section for the IPv6 eth:

post-up sleep 3

Is not really the "stable" method but seems to work. :)

I guess a stable method might be a script that does the "ifconfig add" and then only returns once the IP address is actually available (parse output of "ifconfig eth1" maybe?), and using that script instead of "ifconfig" in the interfaces file.

Yep, certainly:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo eth0 eth1
iface lo inet loopback
 
# The primary network interface
iface eth0 inet static
        address 46.4.181.243
        netmask 255.255.255.240
        broadcast 46.4.181.255
        network 46.4.181.240
        gateway 46.4.181.241
        # dns-* options are implemented by the resolvconf package, if installed
 
iface eth1 inet static
        address 10.0.0.99
        netmask 255.255.255.0
        network 10.0.0.0
 
iface eth1 inet6 static
        pre-up /sbin/modprobe -q ipv6 ; /bin/true
        address 2a01:4f8:101:1ffc::1:1
        netmask 64
        gateway 2a01:4f8:101:1ffc::2
        up /sbin/ifconfig eth1 inet6 add 2a01:4f8:101:1ffc::1:20/64
        up /sbin/ifconfig eth1 inet6 add 2a01:4f8:101:1ffc::1:21/64
        post-up sleep 3

Note that I added that "post-up" command in the last line myself.

I would have expected that the ifconfig commands in /etc/network/interfaces wouldn't return until the IP is ready added ..

Yeah, quite the same here. But it's my only explanation at this time that it doesn't...

Yepp.. Sounds good for now. I'll test this some more with reboots and on another machine, and probably write this mentioned script to see if that idea works too.

In any case, thanks for your help, as usual!