New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lxc-docker startup script fails to set up iptables MASQ rule; WAS: dns issues while using docker run -dns #866

Closed
ml10 opened this Issue Jun 10, 2013 · 40 comments

Comments

Projects
None yet
@ml10

ml10 commented Jun 10, 2013

I need to use -dns args when running docker run, and that was working fine last week. Today, however, it's unable to resolve any requests.

andyh@gir:~$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base ping -c 5 google.com
ping: unknown host google.com
andyh@gir:~$ docker version
Client version: 0.4.0
Server version: 0.4.0
Go version: go1.0.3
andyh@gir:~$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
andyh@gir:~$

I'll dig in with dig to get more details. Any other suggestions for debugging these dns issues?

@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack Jun 10, 2013

Contributor

can you try docker run -dns 8.8.8.8 -dns 8.8.4.4 base cat /etc/resolv.conf ?

Contributor

creack commented Jun 10, 2013

can you try docker run -dns 8.8.8.8 -dns 8.8.4.4 base cat /etc/resolv.conf ?

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Sorry, I had checked that interactively, but forgot to include it above.

andyh@gir:~$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
andyh@gir:~$ 

ml10 commented Jun 10, 2013

Sorry, I had checked that interactively, but forgot to include it above.

andyh@gir:~$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
andyh@gir:~$ 
@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack Jun 10, 2013

Contributor

@jpetazzo Any idea? The resolv.conf looks good.

Contributor

creack commented Jun 10, 2013

@jpetazzo Any idea? The resolv.conf looks good.

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Jun 10, 2013

Contributor

@ml10 Does the network work when not using -dns? It looks like ipv4 forwarding and NAT aren't set up.

cat /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -L -t nat -n
# somewhere in the output you shold see:
MASQUERADE  all  --  172.16.42.0/24      !172.16.42.0/24
Contributor

unclejack commented Jun 10, 2013

@ml10 Does the network work when not using -dns? It looks like ipv4 forwarding and NAT aren't set up.

cat /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -L -t nat -n
# somewhere in the output you shold see:
MASQUERADE  all  --  172.16.42.0/24      !172.16.42.0/24
@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

andyh@gir:~$ docker run base ping -c 5 google.com
ping: unknown host google.com
andyh@gir:~$ cat /proc/sys/net/ipv4/ip_forward 
1
andyh@gir:~$ sudo iptables -L -t nat -n | grep MASQUERADE
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24         
andyh@gir:~$ 

Without the grep there are some DOCKER chains in iptables as well. Would those be useful?

ml10 commented Jun 10, 2013

andyh@gir:~$ docker run base ping -c 5 google.com
ping: unknown host google.com
andyh@gir:~$ cat /proc/sys/net/ipv4/ip_forward 
1
andyh@gir:~$ sudo iptables -L -t nat -n | grep MASQUERADE
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24         
andyh@gir:~$ 

Without the grep there are some DOCKER chains in iptables as well. Would those be useful?

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Ahh... yeah, looks the IP spaces are different between the masquerade setup and what the container is using:

andyh@gir:~$ docker run -i -t base ifconfig
eth0      Link encap:Ethernet  HWaddr 92:6b:bb:f4:46:00  
          inet addr:172.16.42.13  Bcast:172.16.42.255  Mask:255.255.255.0
          inet6 addr: fe80::906b:bbff:fef4:4600/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:90 (90.0 B)  TX bytes:90 (90.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ml10 commented Jun 10, 2013

Ahh... yeah, looks the IP spaces are different between the masquerade setup and what the container is using:

andyh@gir:~$ docker run -i -t base ifconfig
eth0      Link encap:Ethernet  HWaddr 92:6b:bb:f4:46:00  
          inet addr:172.16.42.13  Bcast:172.16.42.255  Mask:255.255.255.0
          inet6 addr: fe80::906b:bbff:fef4:4600/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:90 (90.0 B)  TX bytes:90 (90.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Jun 10, 2013

Contributor

Perhaps you can start docker -d again with docker -d -D to see what's going on with the setup of the iptables rules?

Contributor

unclejack commented Jun 10, 2013

Perhaps you can start docker -d again with docker -d -D to see what's going on with the setup of the iptables rules?

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Nothing jumps out at me from the console. Would there be other logs elsewhere?

andyh@gir:/var/log$ sudo /usr/bin/docker -D -d
[debug] runtime.go:221 Loaded container 1b7763324e094cbc78d0b1097e1fc7cf5bbe7dc4ce78cee46e54bc903019f1eb
... <snip loading other containers> ...
[debug] runtime.go:221 Loaded container fe82e444609d3bc40c6fe99b890ae300c6f8fc3c5af56e95f54af26c3e0116d3
2013/06/10 13:12:49 WARNING: Your kernel does not support cgroup swap limit.
2013/06/10 13:12:49 Listening for HTTP on 127.0.0.1:4243
[debug] api.go:752 Registering POST, /build
... <snip registering other methods> ...
[debug] api.go:752 Registering GET, /containers/{name:.*}/changes
[debug] api.go:758 Calling POST /containers/create
2013/06/10 13:13:15 POST /v1.1/containers/create
[debug] api.go:758 Calling POST /containers/{name:.*}/start
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/start
[debug] container.go:614 Waiting for process
[debug] api.go:758 Calling POST /containers/{name:.*}/resize
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/resize?w=54&h=104
[debug] api.go:758 Calling POST /containers/{name:.*}/attach
[debug] api.go:758 Calling POST /containers/{name:.*}/attach
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/attach?stream=1&logs=1&stdout=1
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/attach?logs=1&stream=1&stderr=1
[debug] container.go:340 [start] attach stdout

[debug] container.go:395 Waiting for job 1/1

[debug] container.go:366 [start] attach stderr

[debug] container.go:395 Waiting for job 1/1

[debug] container.go:624 6c18c39664cf715699a707d36ea73f986e1ba6e755530f2e0aafb6b3ab197999: Process: exit status 2
[debug] container.go:627 Process finished
[debug] container.go:355 [end]  attach stdout

[debug] container.go:381 [end]  attach stderr

[debug] container.go:400 Job 1 completed successfully

[debug] container.go:400 Job 1 completed successfully

[debug] container.go:402 All jobs completed successfully

[debug] container.go:402 All jobs completed successfully

I just noticed that the MASQUERADE iptables chain is still loaded after shutting down the docker daemon...

andyh@gir:/var/log$ ps auwwx | grep docker
andyh    27976  0.0  0.0  13628   960 pts/6    S+   13:19   0:00 grep --color=auto docker
andyh@gir:/var/log$ sudo iptables -L -t nat -n | grep MASQUERADE
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24         

Is that expected? Maybe I somehow have a stale iptables setup that isn't getting refreshed/reloaded?

ml10 commented Jun 10, 2013

Nothing jumps out at me from the console. Would there be other logs elsewhere?

andyh@gir:/var/log$ sudo /usr/bin/docker -D -d
[debug] runtime.go:221 Loaded container 1b7763324e094cbc78d0b1097e1fc7cf5bbe7dc4ce78cee46e54bc903019f1eb
... <snip loading other containers> ...
[debug] runtime.go:221 Loaded container fe82e444609d3bc40c6fe99b890ae300c6f8fc3c5af56e95f54af26c3e0116d3
2013/06/10 13:12:49 WARNING: Your kernel does not support cgroup swap limit.
2013/06/10 13:12:49 Listening for HTTP on 127.0.0.1:4243
[debug] api.go:752 Registering POST, /build
... <snip registering other methods> ...
[debug] api.go:752 Registering GET, /containers/{name:.*}/changes
[debug] api.go:758 Calling POST /containers/create
2013/06/10 13:13:15 POST /v1.1/containers/create
[debug] api.go:758 Calling POST /containers/{name:.*}/start
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/start
[debug] container.go:614 Waiting for process
[debug] api.go:758 Calling POST /containers/{name:.*}/resize
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/resize?w=54&h=104
[debug] api.go:758 Calling POST /containers/{name:.*}/attach
[debug] api.go:758 Calling POST /containers/{name:.*}/attach
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/attach?stream=1&logs=1&stdout=1
2013/06/10 13:13:15 POST /v1.1/containers/6c18c39664cf/attach?logs=1&stream=1&stderr=1
[debug] container.go:340 [start] attach stdout

[debug] container.go:395 Waiting for job 1/1

[debug] container.go:366 [start] attach stderr

[debug] container.go:395 Waiting for job 1/1

[debug] container.go:624 6c18c39664cf715699a707d36ea73f986e1ba6e755530f2e0aafb6b3ab197999: Process: exit status 2
[debug] container.go:627 Process finished
[debug] container.go:355 [end]  attach stdout

[debug] container.go:381 [end]  attach stderr

[debug] container.go:400 Job 1 completed successfully

[debug] container.go:400 Job 1 completed successfully

[debug] container.go:402 All jobs completed successfully

[debug] container.go:402 All jobs completed successfully

I just noticed that the MASQUERADE iptables chain is still loaded after shutting down the docker daemon...

andyh@gir:/var/log$ ps auwwx | grep docker
andyh    27976  0.0  0.0  13628   960 pts/6    S+   13:19   0:00 grep --color=auto docker
andyh@gir:/var/log$ sudo iptables -L -t nat -n | grep MASQUERADE
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24         

Is that expected? Maybe I somehow have a stale iptables setup that isn't getting refreshed/reloaded?

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

I saw a pointer from this askubuntu try starting the daemon with a new bridge interface.

That creates a new MASQUERADE rule

andyh@gir:~/code/docker/docker$ sudo iptables -L POSTROUTING -t nat -n | grep MASQUERADE
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24         
MASQUERADE  all  --  10.0.42.0/24        !10.0.42.0/24        
andyh@gir:~/code/docker/docker$ 

Using the new bridge and specifying the -dns option works:

andyh@gir:~/code/docker/docker$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base ping -c 5 google.com
PING google.com (173.194.46.78) 56(84) bytes of data.
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=1 ttl=53 time=78.6 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=2 ttl=53 time=74.9 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=3 ttl=53 time=67.0 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=4 ttl=53 time=79.1 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=5 ttl=53 time=69.3 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 8170ms
rtt min/avg/max/mdev = 67.061/73.809/79.145/4.869 ms
andyh@gir:~/code/docker/docker$

The 10.0.3.0 address space appears to be used by the default lxc bridge, from my ifconfig:

andyh@gir:~/tmp/strace/dns$ ifconfig 
docker0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:172.16.42.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::b806:6bff:fee5:4bf8/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:512 errors:0 dropped:0 overruns:0 frame:0
          TX packets:244 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:29336 (29.3 KB)  TX bytes:24139 (24.1 KB)

eth0      Link encap:Ethernet  HWaddr d4:be:d9:6a:c4:a9  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:20 Memory:f7700000-f7720000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:87453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:87453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11272312 (11.2 MB)  TX bytes:11272312 (11.2 MB)

lxcbr0    Link encap:Ethernet  HWaddr 56:1e:01:62:4d:99  
          inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::541e:1ff:fe62:4d99/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:21796 (21.7 KB)

testbr0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:10.0.42.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::5c73:a7ff:fe21:a698/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:152 (152.0 B)  TX bytes:8367 (8.3 KB)

wlan0     Link encap:Ethernet  HWaddr 24:77:03:b3:b2:24  
          inet addr:192.168.136.198  Bcast:192.168.136.255  Mask:255.255.255.0
          inet6 addr: fe80::2677:3ff:feb3:b224/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:387946 errors:0 dropped:0 overruns:0 frame:0
          TX packets:238562 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:281539727 (281.5 MB)  TX bytes:48723043 (48.7 MB)

ml10 commented Jun 10, 2013

I saw a pointer from this askubuntu try starting the daemon with a new bridge interface.

That creates a new MASQUERADE rule

andyh@gir:~/code/docker/docker$ sudo iptables -L POSTROUTING -t nat -n | grep MASQUERADE
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24         
MASQUERADE  all  --  10.0.42.0/24        !10.0.42.0/24        
andyh@gir:~/code/docker/docker$ 

Using the new bridge and specifying the -dns option works:

andyh@gir:~/code/docker/docker$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base ping -c 5 google.com
PING google.com (173.194.46.78) 56(84) bytes of data.
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=1 ttl=53 time=78.6 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=2 ttl=53 time=74.9 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=3 ttl=53 time=67.0 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=4 ttl=53 time=79.1 ms
64 bytes from ord08s11-in-f14.1e100.net (173.194.46.78): icmp_req=5 ttl=53 time=69.3 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 8170ms
rtt min/avg/max/mdev = 67.061/73.809/79.145/4.869 ms
andyh@gir:~/code/docker/docker$

The 10.0.3.0 address space appears to be used by the default lxc bridge, from my ifconfig:

andyh@gir:~/tmp/strace/dns$ ifconfig 
docker0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:172.16.42.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::b806:6bff:fee5:4bf8/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:512 errors:0 dropped:0 overruns:0 frame:0
          TX packets:244 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:29336 (29.3 KB)  TX bytes:24139 (24.1 KB)

eth0      Link encap:Ethernet  HWaddr d4:be:d9:6a:c4:a9  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:20 Memory:f7700000-f7720000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:87453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:87453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11272312 (11.2 MB)  TX bytes:11272312 (11.2 MB)

lxcbr0    Link encap:Ethernet  HWaddr 56:1e:01:62:4d:99  
          inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::541e:1ff:fe62:4d99/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:21796 (21.7 KB)

testbr0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:10.0.42.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::5c73:a7ff:fe21:a698/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:152 (152.0 B)  TX bytes:8367 (8.3 KB)

wlan0     Link encap:Ethernet  HWaddr 24:77:03:b3:b2:24  
          inet addr:192.168.136.198  Bcast:192.168.136.255  Mask:255.255.255.0
          inet6 addr: fe80::2677:3ff:feb3:b224/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:387946 errors:0 dropped:0 overruns:0 frame:0
          TX packets:238562 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:281539727 (281.5 MB)  TX bytes:48723043 (48.7 MB)
@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Jun 10, 2013

Contributor

@ml10 Could you paste the output strace for docker -d, please? That would help track this down.

Please post the output of ip route as well, just in case docker runs into some kind of issue with it and fails to set up iptables because of it.

Contributor

unclejack commented Jun 10, 2013

@ml10 Could you paste the output strace for docker -d, please? That would help track this down.

Please post the output of ip route as well, just in case docker runs into some kind of issue with it and fails to set up iptables because of it.

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Would you need the strace output of docker -d just on startup or after running a container?

andyh@gir:~/code/docker/docker$ sudo ip route
default via 192.168.136.1 dev wlan0  proto static 
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1 
10.0.42.0/24 dev testbr0  proto kernel  scope link  src 10.0.42.1 
169.254.0.0/16 dev wlan0  scope link  metric 1000 
172.16.42.0/24 dev docker0  proto kernel  scope link  src 172.16.42.1 
192.168.136.0/24 dev wlan0  proto kernel  scope link  src 192.168.136.198  metric 9 
andyh@gir:~/code/docker/docker$

ml10 commented Jun 10, 2013

Would you need the strace output of docker -d just on startup or after running a container?

andyh@gir:~/code/docker/docker$ sudo ip route
default via 192.168.136.1 dev wlan0  proto static 
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1 
10.0.42.0/24 dev testbr0  proto kernel  scope link  src 10.0.42.1 
169.254.0.0/16 dev wlan0  scope link  metric 1000 
172.16.42.0/24 dev docker0  proto kernel  scope link  src 172.16.42.1 
192.168.136.0/24 dev wlan0  proto kernel  scope link  src 192.168.136.198  metric 9 
andyh@gir:~/code/docker/docker$
@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack Jun 10, 2013

Contributor

@ml10 can you try to reset everything?

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d

It will force docker to recreate the bridge and reinit all the network rules

Contributor

creack commented Jun 10, 2013

@ml10 can you try to reset everything?

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d

It will force docker to recreate the bridge and reinit all the network rules

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Jun 10, 2013

Contributor

The strace output of the docker -d startup would be enough, that's when iptables gets set up.

If the issue still occurs after you reset as advised above, please post the strace output.

Contributor

unclejack commented Jun 10, 2013

The strace output of the docker -d startup would be enough, that's when iptables gets set up.

If the issue still occurs after you reset as advised above, please post the strace output.

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Resetting as above seems to clear things up

andyh@gir:~/code/docker/docker$ sudo iptables -L  -t nat -n 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  172.16.42.0/24      !172.16.42.0/24      

Chain DOCKER (2 references)
target     prot opt source               destination         
andyh@gir:~/code/docker/docker$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base ping -c 5 google.com
PING google.com (173.194.46.67) 56(84) bytes of data.
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=1 ttl=53 time=69.4 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=2 ttl=53 time=71.7 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=3 ttl=53 time=70.5 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=4 ttl=53 time=60.7 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=5 ttl=53 time=53.6 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 53.622/65.233/71.757/6.981 ms
andyh@gir:~/code/docker/docker$ 

I have the strace output from docker -d from before clearing out the networking stuff. Let me know if it would be useful.

ml10 commented Jun 10, 2013

Resetting as above seems to clear things up

andyh@gir:~/code/docker/docker$ sudo iptables -L  -t nat -n 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  172.16.42.0/24      !172.16.42.0/24      

Chain DOCKER (2 references)
target     prot opt source               destination         
andyh@gir:~/code/docker/docker$ docker run -dns 8.8.8.8 -dns 8.8.4.4 base ping -c 5 google.com
PING google.com (173.194.46.67) 56(84) bytes of data.
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=1 ttl=53 time=69.4 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=2 ttl=53 time=71.7 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=3 ttl=53 time=70.5 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=4 ttl=53 time=60.7 ms
64 bytes from ord08s11-in-f3.1e100.net (173.194.46.67): icmp_req=5 ttl=53 time=53.6 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 53.622/65.233/71.757/6.981 ms
andyh@gir:~/code/docker/docker$ 

I have the strace output from docker -d from before clearing out the networking stuff. Let me know if it would be useful.

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Thanks for your help as well!

ml10 commented Jun 10, 2013

Thanks for your help as well!

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 10, 2013

Going through the docker logs from this morning, I see this:

2013/06/10 08:14:25 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE

I missed it initially because the logs rolled, but the NAT rule was not successfully applied on boot this morning.

ml10 commented Jun 10, 2013

Going through the docker logs from this morning, I see this:

2013/06/10 08:14:25 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE

I missed it initially because the logs rolled, but the NAT rule was not successfully applied on boot this morning.

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 11, 2013

This morning, on boot, I noticed the same error from the docker logs:

2013/06/11 08:11:33 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE

ml10 commented Jun 11, 2013

This morning, on boot, I noticed the same error from the docker logs:

2013/06/11 08:11:33 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 11, 2013

Ok, here's a summary for the last 12 days:

andyh@gir:/var/log/upstart$ sudo zgrep -h -e "iptables failed" -e "Listening for HTTP" docker.log.7.gz docker.log.6.gz docker.log.5.gz docker.log.4.gz docker.log.3.gz docker.log.2.gz docker.log.1.gz 
2013/05/31 08:05:07 Listening for HTTP on 0.0.0.0:4243
2013/06/03 08:34:30 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/03 08:34:30 Listening for HTTP on 0.0.0.0:4243
2013/06/03 08:38:26 Listening for HTTP on 127.0.0.1:4243
2013/06/04 08:09:15 Listening for HTTP on 127.0.0.1:4243
2013/06/04 08:32:02 Listening for HTTP on 127.0.0.1:4243
2013/06/04 11:37:49 Listening for HTTP on 127.0.0.1:4243
2013/06/04 13:56:42 Listening for HTTP on 127.0.0.1:4243
2013/06/04 15:11:41 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/04 15:11:41 Listening for HTTP on 127.0.0.1:4243
2013/06/04 16:06:47 Listening for HTTP on 127.0.0.1:4243
2013/06/05 08:13:19 Listening for HTTP on 127.0.0.1:4243
2013/06/06 08:39:36 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/06 08:39:36 Listening for HTTP on 127.0.0.1:4243
2013/06/07 08:12:10 Listening for HTTP on 127.0.0.1:4243
2013/06/10 08:14:25 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/10 08:14:25 Listening for HTTP on 127.0.0.1:4243
2013/06/10 11:39:06 Listening for HTTP on 127.0.0.1:4243
2013/06/10 11:39:49 Listening for HTTP on 127.0.0.1:4243
2013/06/10 13:06:37 Listening for HTTP on 127.0.0.1:4243
2013/06/10 13:07:26 Listening for HTTP on 127.0.0.1:4243
2013/06/10 13:52:38 Listening for HTTP on 127.0.0.1:4243
2013/06/11 08:11:33 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/11 08:11:33 Listening for HTTP on 127.0.0.1:4243
andyh@gir:/var/log/upstart$ 

This morning I just reapplied the nat rule with sudo iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE.

ml10 commented Jun 11, 2013

Ok, here's a summary for the last 12 days:

andyh@gir:/var/log/upstart$ sudo zgrep -h -e "iptables failed" -e "Listening for HTTP" docker.log.7.gz docker.log.6.gz docker.log.5.gz docker.log.4.gz docker.log.3.gz docker.log.2.gz docker.log.1.gz 
2013/05/31 08:05:07 Listening for HTTP on 0.0.0.0:4243
2013/06/03 08:34:30 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/03 08:34:30 Listening for HTTP on 0.0.0.0:4243
2013/06/03 08:38:26 Listening for HTTP on 127.0.0.1:4243
2013/06/04 08:09:15 Listening for HTTP on 127.0.0.1:4243
2013/06/04 08:32:02 Listening for HTTP on 127.0.0.1:4243
2013/06/04 11:37:49 Listening for HTTP on 127.0.0.1:4243
2013/06/04 13:56:42 Listening for HTTP on 127.0.0.1:4243
2013/06/04 15:11:41 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/04 15:11:41 Listening for HTTP on 127.0.0.1:4243
2013/06/04 16:06:47 Listening for HTTP on 127.0.0.1:4243
2013/06/05 08:13:19 Listening for HTTP on 127.0.0.1:4243
2013/06/06 08:39:36 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/06 08:39:36 Listening for HTTP on 127.0.0.1:4243
2013/06/07 08:12:10 Listening for HTTP on 127.0.0.1:4243
2013/06/10 08:14:25 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/10 08:14:25 Listening for HTTP on 127.0.0.1:4243
2013/06/10 11:39:06 Listening for HTTP on 127.0.0.1:4243
2013/06/10 11:39:49 Listening for HTTP on 127.0.0.1:4243
2013/06/10 13:06:37 Listening for HTTP on 127.0.0.1:4243
2013/06/10 13:07:26 Listening for HTTP on 127.0.0.1:4243
2013/06/10 13:52:38 Listening for HTTP on 127.0.0.1:4243
2013/06/11 08:11:33 Unable to enable network bridge NAT: iptables failed: iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE
2013/06/11 08:11:33 Listening for HTTP on 127.0.0.1:4243
andyh@gir:/var/log/upstart$ 

This morning I just reapplied the nat rule with sudo iptables -t nat -A POSTROUTING -s 172.16.42.1/24 ! -d 172.16.42.1/24 -j MASQUERADE.

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Jun 14, 2013

Contributor

I've run tail -f on the output of strace -f while starting and stopping docker built with Go 1.1.1.
There was no single failure and docker was always able to set up iptables properly, including the MASQUERADE rule.

After a few hundreds of runs which were showing me a new execve("/sbin/iptables", ["/sbin/iptables", "-t", "nat", "-A", "POSTROUTING", "-s", "172.16.42.1/24", "!", "-d", "172.16.42.1/24", "-j", "MASQUERADE"] every 1 second, I can say that this issue should be fixed by using a docker binary built with Go 1.1.1.

The docker binary releases are already being built with Go 1.1.1. The PPA packages will also be built with this version of Go when the golang PPA gets updated.

Contributor

unclejack commented Jun 14, 2013

I've run tail -f on the output of strace -f while starting and stopping docker built with Go 1.1.1.
There was no single failure and docker was always able to set up iptables properly, including the MASQUERADE rule.

After a few hundreds of runs which were showing me a new execve("/sbin/iptables", ["/sbin/iptables", "-t", "nat", "-A", "POSTROUTING", "-s", "172.16.42.1/24", "!", "-d", "172.16.42.1/24", "-j", "MASQUERADE"] every 1 second, I can say that this issue should be fixed by using a docker binary built with Go 1.1.1.

The docker binary releases are already being built with Go 1.1.1. The PPA packages will also be built with this version of Go when the golang PPA gets updated.

@ml10 ml10 referenced this issue Jun 26, 2013

Closed

Network Issue #1026

@ml10

This comment has been minimized.

Show comment
Hide comment
@ml10

ml10 Jun 26, 2013

updating with better summary now that the discovery is done.

ml10 commented Jun 26, 2013

updating with better summary now that the discovery is done.

@hugoduncan

This comment has been minimized.

Show comment
Hide comment
@hugoduncan

hugoduncan Jun 27, 2013

Contributor

On a host with 0.4.6 installed via ppa, networking was not working in the containers.

This comment resolved the issue for me.

iptable rules:

Contributor

hugoduncan commented Jun 27, 2013

On a host with 0.4.6 installed via ppa, networking was not working in the containers.

This comment resolved the issue for me.

iptable rules:

@metalivedev

This comment has been minimized.

Show comment
Hide comment
@metalivedev

metalivedev Jul 20, 2013

Contributor

happened today for me with fresh vm and fresh 0.5.0 installation. Cleaning out the iptables fixed it for me, but they're not getting set up properly the first time.

Contributor

metalivedev commented Jul 20, 2013

happened today for me with fresh vm and fresh 0.5.0 installation. Cleaning out the iptables fixed it for me, but they're not getting set up properly the first time.

@frankscholten

This comment has been minimized.

Show comment
Hide comment
@frankscholten

frankscholten Jul 23, 2013

Got the same issue while going the node.js app tutorial. Like @metalivedev only after cleaning iptables it can ping out from the container.

Got the same issue while going the node.js app tutorial. Like @metalivedev only after cleaning iptables it can ping out from the container.

@liamcurry

This comment has been minimized.

Show comment
Hide comment
@liamcurry

liamcurry Aug 1, 2013

Ran into this issue today during a fresh install of 0.5.0; following the instructions from this comment made it work for me.

Ran into this issue today during a fresh install of 0.5.0; following the instructions from this comment made it work for me.

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Aug 15, 2013

Contributor

@liamcurry @frankscholten

Do you happen to have custom iptable setups? Are you experiencing this issue anymore on install?

Contributor

crosbymichael commented Aug 15, 2013

@liamcurry @frankscholten

Do you happen to have custom iptable setups? Are you experiencing this issue anymore on install?

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Aug 16, 2013

Contributor

I'm going to go ahead and close this issue. I cannot reproduce in master but if you are still experiencing problems after the 0.6 release feel free to re-open.

Contributor

crosbymichael commented Aug 16, 2013

I'm going to go ahead and close this issue. I cannot reproduce in master but if you are still experiencing problems after the 0.6 release feel free to re-open.

@mboersma

This comment has been minimized.

Show comment
Hide comment
@mboersma

mboersma Sep 25, 2013

I've run into the same issue in an odd way while provisioning a Deis controller. I assigned an EC2 Elastic IP address to the host while it was still installing stuff, which changed its IP address, but docker didn't catch on to related iptables changes.

If docker could recreate its iptables rules on each daemon restart, or somehow listen for network interface changes on the host and adjust accordingly...That Would Be Great. :)

I've run into the same issue in an odd way while provisioning a Deis controller. I assigned an EC2 Elastic IP address to the host while it was still installing stuff, which changed its IP address, but docker didn't catch on to related iptables changes.

If docker could recreate its iptables rules on each daemon restart, or somehow listen for network interface changes on the host and adjust accordingly...That Would Be Great. :)

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2013

I still see this with Docker v0.7.1 on Gentoo:

# docker version
Client version: 0.7.1
Go version (client): go1.1.2
Git commit (client): 88df052
2013/12/09 16:13:24 dial unix /var/run/docker.sock: no such file or directory
# uname -a
Linux nott 3.10.17-gentoo #4 SMP Mon Dec 9 15:42:05 PST 2013 x86_64 AMD A8-5500 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
# iptables -t nat -F
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 
# ifconfig docker0 down
# brctl delbr docker0
# strace -o /tmp/trace docker -d
[/var/lib/docker|a45a551b] +job initapi()
[/var/lib/docker|a45a551b.initapi()] Creating server
Unable to enable network bridge NAT: iptables failed: iptables -A POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE: iptables: No chain/target/match by that name.
 (exit status 1)[/var/lib/docker|a45a551b] -job initapi() = ERR (1)
2013/12/09 16:15:01 initapi:  (exit status 1)
# cat /tmp/trace
…
stat("/bin/iptables", 0xc2001805a0)     = -1 ENOENT (No such file or directory)
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=87616, ...}) = 0
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=87616, ...}) = 0
open("/dev/null", O_RDONLY|O_CLOEXEC)   = 5
pipe2([6, 7], O_CLOEXEC)                = 0
pipe2([8, 9], O_CLOEXEC)                = 0
fork()                                  = 7854
close(9)                                = 0
read(8, "", 8)                          = 0
close(8)                                = 0
close(5)                                = 0
close(7)                                = 0
wait4(7854, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, {ru_utime={0, 0}, ru_stime={0, 1000}, ...}) = 7854
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7854, si_status=1, si_utime=0, si_stime=0} ---
rt_sigreturn()                          = 7854
read(6, "iptables: No chain/target/match "..., 512) = 46
read(6, "", 1490)                       = 0
close(6)                                = 0
write(2, "Unable to enable network bridge "..., 200) = 200
write(2, "[/var/lib/docker|a45a551b] -job "..., 52) = 52
…

I'm happy to move this to a new issue if it's something Gentoo-specific.

wking commented Dec 10, 2013

I still see this with Docker v0.7.1 on Gentoo:

# docker version
Client version: 0.7.1
Go version (client): go1.1.2
Git commit (client): 88df052
2013/12/09 16:13:24 dial unix /var/run/docker.sock: no such file or directory
# uname -a
Linux nott 3.10.17-gentoo #4 SMP Mon Dec 9 15:42:05 PST 2013 x86_64 AMD A8-5500 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
# iptables -t nat -F
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 
# ifconfig docker0 down
# brctl delbr docker0
# strace -o /tmp/trace docker -d
[/var/lib/docker|a45a551b] +job initapi()
[/var/lib/docker|a45a551b.initapi()] Creating server
Unable to enable network bridge NAT: iptables failed: iptables -A POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE: iptables: No chain/target/match by that name.
 (exit status 1)[/var/lib/docker|a45a551b] -job initapi() = ERR (1)
2013/12/09 16:15:01 initapi:  (exit status 1)
# cat /tmp/trace
…
stat("/bin/iptables", 0xc2001805a0)     = -1 ENOENT (No such file or directory)
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=87616, ...}) = 0
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=87616, ...}) = 0
open("/dev/null", O_RDONLY|O_CLOEXEC)   = 5
pipe2([6, 7], O_CLOEXEC)                = 0
pipe2([8, 9], O_CLOEXEC)                = 0
fork()                                  = 7854
close(9)                                = 0
read(8, "", 8)                          = 0
close(8)                                = 0
close(5)                                = 0
close(7)                                = 0
wait4(7854, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, {ru_utime={0, 0}, ru_stime={0, 1000}, ...}) = 7854
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7854, si_status=1, si_utime=0, si_stime=0} ---
rt_sigreturn()                          = 7854
read(6, "iptables: No chain/target/match "..., 512) = 46
read(6, "", 1490)                       = 0
close(6)                                = 0
write(2, "Unable to enable network bridge "..., 200) = 200
write(2, "[/var/lib/docker|a45a551b] -job "..., 52) = 52
…

I'm happy to move this to a new issue if it's something Gentoo-specific.

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2013

Ah, I left this out of my previous comment:

# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

wking commented Dec 10, 2013

Ah, I left this out of my previous comment:

# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2013

More info (following #1734):

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

wking commented Dec 10, 2013

More info (following #1734):

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2013

Aha! I was missing IP_NF_TARGET_MASQUERADE (and possibly IP6_NF_TARGET_MASQUERADE). I enabled those and compiled and installed the new modules, after which docker -d works (pulling in a new ipt_MASQUERADE module).

wking commented Dec 10, 2013

Aha! I was missing IP_NF_TARGET_MASQUERADE (and possibly IP6_NF_TARGET_MASQUERADE). I enabled those and compiled and installed the new modules, after which docker -d works (pulling in a new ipt_MASQUERADE module).

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Dec 10, 2013

Member

Thanks for coming back to us @wking - I'll add a check for that to the ebuild (many thanks for reporting it!). :)

Member

tianon commented Dec 10, 2013

Thanks for coming back to us @wking - I'll add a check for that to the ebuild (many thanks for reporting it!). :)

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2013

On Mon, Dec 09, 2013 at 05:37:24PM -0800, Tianon Gravi wrote:

I'll add a check for that to the ebuild (many thanks for reporting
it!). :)

I cloned your repo in prepraration for a PR, but then I stopped for
dinner ;). I'm happy to submit a PR if you like, or I can leave it up
to you…

wking commented Dec 10, 2013

On Mon, Dec 09, 2013 at 05:37:24PM -0800, Tianon Gravi wrote:

I'll add a check for that to the ebuild (many thanks for reporting
it!). :)

I cloned your repo in prepraration for a PR, but then I stopped for
dinner ;). I'm happy to submit a PR if you like, or I can leave it up
to you…

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Dec 10, 2013

Member

I honestly prefer issues, since I have to update the Manifest anyways, but it's already added. :)

Member

tianon commented Dec 10, 2013

I honestly prefer issues, since I have to update the Manifest anyways, but it's already added. :)

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2013

On Mon, Dec 09, 2013 at 05:58:15PM -0800, Tianon Gravi wrote:

but it's already added. :)

Thanks :).

wking commented Dec 10, 2013

On Mon, Dec 09, 2013 at 05:58:15PM -0800, Tianon Gravi wrote:

but it's already added. :)

Thanks :).

@xtagon

This comment has been minimized.

Show comment
Hide comment
@xtagon

xtagon May 13, 2014

I'm having what looks like the same error running 0.10.0 for the first time, also on Gentoo. Here's my output of docker -d -D after a fresh emerge:

[/var/lib/docker|241f183b] +job serveapi(unix:///var/run/docker.sock)
[/var/lib/docker|241f183b] +job initserver()
[/var/lib/docker|241f183b.initserver()] Creating server
2014/05/13 16:05:14 Listening for HTTP on unix (/var/run/docker.sock)
[debug] server.go:1048 Registering GET, /info
[debug] server.go:1048 Registering GET, /images/viz
[debug] server.go:1048 Registering GET, /containers/{name:.*}/top
[debug] server.go:1048 Registering GET, /images/json
[debug] server.go:1048 Registering GET, /images/{name:.*}/json
[debug] server.go:1048 Registering GET, /containers/{name:.*}/attach/ws
[debug] server.go:1048 Registering GET, /version
[debug] server.go:1048 Registering GET, /containers/ps
[debug] server.go:1048 Registering GET, /containers/{name:.*}/changes
[debug] server.go:1048 Registering GET, /events
[debug] server.go:1048 Registering GET, /images/search
[debug] server.go:1048 Registering GET, /images/{name:.*}/get
[debug] server.go:1048 Registering GET, /images/{name:.*}/history
[debug] server.go:1048 Registering GET, /containers/json
[debug] server.go:1048 Registering GET, /containers/{name:.*}/export
[debug] server.go:1048 Registering GET, /containers/{name:.*}/json
[debug] server.go:1048 Registering POST, /commit
[debug] server.go:1048 Registering POST, /images/{name:.*}/tag
[debug] server.go:1048 Registering POST, /containers/create
[debug] server.go:1048 Registering POST, /containers/{name:.*}/kill
[debug] server.go:1048 Registering POST, /containers/{name:.*}/stop
[debug] server.go:1048 Registering POST, /containers/{name:.*}/resize
[debug] server.go:1048 Registering POST, /auth
[debug] server.go:1048 Registering POST, /images/{name:.*}/insert
[debug] server.go:1048 Registering POST, /images/create
[debug] server.go:1048 Registering POST, /images/load
[debug] server.go:1048 Registering POST, /images/{name:.*}/push
[debug] server.go:1048 Registering POST, /containers/{name:.*}/start
[debug] server.go:1048 Registering POST, /build
[debug] server.go:1048 Registering POST, /containers/{name:.*}/restart
[debug] driver.go:78 Error loading driver aufs: No such driver: aufs
[debug] driver.go:78 Error loading driver btrfs: No such driver: btrfs
[debug] deviceset.go:528 Generated prefix: docker-8:4-7209264
[debug] deviceset.go:531 Checking for existence of the pool 'docker-8:4-7209264-pool'
[debug] deviceset.go:545 Pool doesn't exist. Creating it.
[debug] deviceset.go:408 libdevmapper(3): ioctl/libdm-iface.c:1768 (-1) device-mapper: reload ioctl on docker-8:4-7209264-pool failed: Invalid argument
[debug] deviceset.go:562 
--->Err: Error running DeviceCreate (createPool)

[debug] driver.go:78 Error loading driver devicemapper: Error running DeviceCreate (createPool)
[debug] runtime.go:690 Using graph driver vfs
[debug] runtime.go:707 Creating images graph
[debug] graph.go:63 Restored 0 elements
[debug] runtime.go:719 Creating volumes graph
[debug] graph.go:63 Restored 0 elements
[debug] runtime.go:724 Creating repository list
[/var/lib/docker|241f183b] +job init_networkdriver()
[DEBUG] [iptables]: /sbin/iptables, [-C POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
[DEBUG] [iptables]: /sbin/iptables, [-I POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
Unable to enable network bridge NAT: iptables failed: iptables -I POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE: iptables v1.4.20: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
 (exit status 3)
[debug] server.go:1048 Registering POST, /containers/{name:.*}/wait
[debug] server.go:1048 Registering POST, /containers/{name:.*}/attach
[debug] server.go:1048 Registering POST, /containers/{name:.*}/copy
[debug] server.go:1048 Registering DELETE, /containers/{name:.*}
[debug] server.go:1048 Registering DELETE, /images/{name:.*}
[debug] server.go:1048 Registering OPTIONS, 
[debug] server.go:1138 docker group found. gid: 105
[/var/lib/docker|241f183b] -job init_networkdriver() = ERR (1)
 (exit status 3)
[/var/lib/docker|241f183b] -job initserver() = ERR (1)
2014/05/13 16:05:14  (exit status 3)

My versions are:

$ docker version
Client version: 0.10.0
Client API version: 1.10
Go version (client): go1.2
Git commit (client): dc9c28f

$ uname -a
Linux kantu 3.12.13-gentoo #1 SMP Wed Apr 16 15:22:08 PDT 2014 x86_64 Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz GenuineIntel GNU/Linux

@wking, since you solved the issue for yourself, would you mind explaining how you did it? I'm new to Docker and I would appreciate it greatly.

xtagon commented May 13, 2014

I'm having what looks like the same error running 0.10.0 for the first time, also on Gentoo. Here's my output of docker -d -D after a fresh emerge:

[/var/lib/docker|241f183b] +job serveapi(unix:///var/run/docker.sock)
[/var/lib/docker|241f183b] +job initserver()
[/var/lib/docker|241f183b.initserver()] Creating server
2014/05/13 16:05:14 Listening for HTTP on unix (/var/run/docker.sock)
[debug] server.go:1048 Registering GET, /info
[debug] server.go:1048 Registering GET, /images/viz
[debug] server.go:1048 Registering GET, /containers/{name:.*}/top
[debug] server.go:1048 Registering GET, /images/json
[debug] server.go:1048 Registering GET, /images/{name:.*}/json
[debug] server.go:1048 Registering GET, /containers/{name:.*}/attach/ws
[debug] server.go:1048 Registering GET, /version
[debug] server.go:1048 Registering GET, /containers/ps
[debug] server.go:1048 Registering GET, /containers/{name:.*}/changes
[debug] server.go:1048 Registering GET, /events
[debug] server.go:1048 Registering GET, /images/search
[debug] server.go:1048 Registering GET, /images/{name:.*}/get
[debug] server.go:1048 Registering GET, /images/{name:.*}/history
[debug] server.go:1048 Registering GET, /containers/json
[debug] server.go:1048 Registering GET, /containers/{name:.*}/export
[debug] server.go:1048 Registering GET, /containers/{name:.*}/json
[debug] server.go:1048 Registering POST, /commit
[debug] server.go:1048 Registering POST, /images/{name:.*}/tag
[debug] server.go:1048 Registering POST, /containers/create
[debug] server.go:1048 Registering POST, /containers/{name:.*}/kill
[debug] server.go:1048 Registering POST, /containers/{name:.*}/stop
[debug] server.go:1048 Registering POST, /containers/{name:.*}/resize
[debug] server.go:1048 Registering POST, /auth
[debug] server.go:1048 Registering POST, /images/{name:.*}/insert
[debug] server.go:1048 Registering POST, /images/create
[debug] server.go:1048 Registering POST, /images/load
[debug] server.go:1048 Registering POST, /images/{name:.*}/push
[debug] server.go:1048 Registering POST, /containers/{name:.*}/start
[debug] server.go:1048 Registering POST, /build
[debug] server.go:1048 Registering POST, /containers/{name:.*}/restart
[debug] driver.go:78 Error loading driver aufs: No such driver: aufs
[debug] driver.go:78 Error loading driver btrfs: No such driver: btrfs
[debug] deviceset.go:528 Generated prefix: docker-8:4-7209264
[debug] deviceset.go:531 Checking for existence of the pool 'docker-8:4-7209264-pool'
[debug] deviceset.go:545 Pool doesn't exist. Creating it.
[debug] deviceset.go:408 libdevmapper(3): ioctl/libdm-iface.c:1768 (-1) device-mapper: reload ioctl on docker-8:4-7209264-pool failed: Invalid argument
[debug] deviceset.go:562 
--->Err: Error running DeviceCreate (createPool)

[debug] driver.go:78 Error loading driver devicemapper: Error running DeviceCreate (createPool)
[debug] runtime.go:690 Using graph driver vfs
[debug] runtime.go:707 Creating images graph
[debug] graph.go:63 Restored 0 elements
[debug] runtime.go:719 Creating volumes graph
[debug] graph.go:63 Restored 0 elements
[debug] runtime.go:724 Creating repository list
[/var/lib/docker|241f183b] +job init_networkdriver()
[DEBUG] [iptables]: /sbin/iptables, [-C POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
[DEBUG] [iptables]: /sbin/iptables, [-I POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
Unable to enable network bridge NAT: iptables failed: iptables -I POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE: iptables v1.4.20: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
 (exit status 3)
[debug] server.go:1048 Registering POST, /containers/{name:.*}/wait
[debug] server.go:1048 Registering POST, /containers/{name:.*}/attach
[debug] server.go:1048 Registering POST, /containers/{name:.*}/copy
[debug] server.go:1048 Registering DELETE, /containers/{name:.*}
[debug] server.go:1048 Registering DELETE, /images/{name:.*}
[debug] server.go:1048 Registering OPTIONS, 
[debug] server.go:1138 docker group found. gid: 105
[/var/lib/docker|241f183b] -job init_networkdriver() = ERR (1)
 (exit status 3)
[/var/lib/docker|241f183b] -job initserver() = ERR (1)
2014/05/13 16:05:14  (exit status 3)

My versions are:

$ docker version
Client version: 0.10.0
Client API version: 1.10
Go version (client): go1.2
Git commit (client): dc9c28f

$ uname -a
Linux kantu 3.12.13-gentoo #1 SMP Wed Apr 16 15:22:08 PDT 2014 x86_64 Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz GenuineIntel GNU/Linux

@wking, since you solved the issue for yourself, would you mind explaining how you did it? I'm new to Docker and I would appreciate it greatly.

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 14, 2014

On Tue, May 13, 2014 at 04:10:15PM -0700, Justin Workman wrote:

[DEBUG] [iptables]: /sbin/iptables, [-C POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
[DEBUG] [iptables]: /sbin/iptables, [-I POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
Unable to enable network bridge NAT: iptables failed: iptables -I
POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j
MASQUERADE: iptables v1.4.20: can't initialize iptables table
`nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
(exit status 3)

Missing the 'nat' table is a symptom of missing kernel modules.

@wking, since you solved the issue for yourself, would you mind
explaining how you did it? I'm new to Docker and I would appreciate
it greatly.

As I mentioned in 1, I was missing IP_NF_TARGET_MASQUERADE in my
kernel config. I enabled that config with menuconfig, recompiled my
kernel, rebooted onto the new kernel, and ran 'docker -d', after which
'lsmod' listed ipt_MASQUERADE. There are a number of kernel configs
that @tianon's ebuild checks for, so you may be missing something
other than IP_NF_TARGET_MASQUERADE. Did you pay attention to any
warnings spit out by the emerge? If not, it's probably easiest to
re-emerge docker and paste any warnings here. If you don't get
warnings, you can try looking through the config settings @tianon
checks by hand 2, and seeing if they're in the kernel you're
running. Good luck :).

wking commented May 14, 2014

On Tue, May 13, 2014 at 04:10:15PM -0700, Justin Workman wrote:

[DEBUG] [iptables]: /sbin/iptables, [-C POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
[DEBUG] [iptables]: /sbin/iptables, [-I POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j MASQUERADE]
Unable to enable network bridge NAT: iptables failed: iptables -I
POSTROUTING -t nat -s 172.17.42.1/16 ! -d 172.17.42.1/16 -j
MASQUERADE: iptables v1.4.20: can't initialize iptables table
`nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
(exit status 3)

Missing the 'nat' table is a symptom of missing kernel modules.

@wking, since you solved the issue for yourself, would you mind
explaining how you did it? I'm new to Docker and I would appreciate
it greatly.

As I mentioned in 1, I was missing IP_NF_TARGET_MASQUERADE in my
kernel config. I enabled that config with menuconfig, recompiled my
kernel, rebooted onto the new kernel, and ran 'docker -d', after which
'lsmod' listed ipt_MASQUERADE. There are a number of kernel configs
that @tianon's ebuild checks for, so you may be missing something
other than IP_NF_TARGET_MASQUERADE. Did you pay attention to any
warnings spit out by the emerge? If not, it's probably easiest to
re-emerge docker and paste any warnings here. If you don't get
warnings, you can try looking through the config settings @tianon
checks by hand 2, and seeing if they're in the kernel you're
running. Good luck :).

runcom added a commit to runcom/docker that referenced this issue Jan 28, 2016

backport: libnetwork #771 and #866
Signed-off-by: Antonio Murdaca <runcom@redhat.com>

rhatdan added a commit to projectatomic/docker that referenced this issue Jan 28, 2016

@ldesousa

This comment has been minimized.

Show comment
Hide comment
@ldesousa

ldesousa Dec 4, 2017

I just bumped into this issue with Docker 17.09:

$ docker run ubuntu:16.04 apt-get update
Err:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:2 http://archive.ubuntu.com/ubuntu xenial InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary failure resolving 'security.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

My system:

$ docker version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ uname -a
Linux luis-workstation 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

The solution proposed by @creack does not not function since there is no -d flag in this docker version.

ldesousa commented Dec 4, 2017

I just bumped into this issue with Docker 17.09:

$ docker run ubuntu:16.04 apt-get update
Err:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:2 http://archive.ubuntu.com/ubuntu xenial InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary failure resolving 'security.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

My system:

$ docker version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ uname -a
Linux luis-workstation 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

The solution proposed by @creack does not not function since there is no -d flag in this docker version.

@BowsilAmee

This comment has been minimized.

Show comment
Hide comment
@BowsilAmee

BowsilAmee Jul 17, 2018

Dear Team,

I am facing wired issue on my docker container every 20 -24 hrs my docker unable to reach the host

when i reset the docker container then it will run for next 20hrs again i have to fallow the same cycle every day :( not sure why this is happening

Error message when try to curl from the container

root@a01b581b758c:/usr/local/waent# curl -X GET \

https://www.google.com\       curl -X GET \
https://www.google.com\

curl: (6) Could not resolve host: www.google.com
curl: (6) Could not resolve host: curl
curl: (6) Could not resolve host: www.google.com
root@a01b581b758c:/usr/local/waent# ping
bash: ping: command not found

On the other hand when i try from VM i am able to reach the domain

BowsilAmee commented Jul 17, 2018

Dear Team,

I am facing wired issue on my docker container every 20 -24 hrs my docker unable to reach the host

when i reset the docker container then it will run for next 20hrs again i have to fallow the same cycle every day :( not sure why this is happening

Error message when try to curl from the container

root@a01b581b758c:/usr/local/waent# curl -X GET \

https://www.google.com\       curl -X GET \
https://www.google.com\

curl: (6) Could not resolve host: www.google.com
curl: (6) Could not resolve host: curl
curl: (6) Could not resolve host: www.google.com
root@a01b581b758c:/usr/local/waent# ping
bash: ping: command not found

On the other hand when i try from VM i am able to reach the domain

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jul 23, 2018

Member

I'm locking the conversation on this issue; this issue is over 5 years old, and literally all code that was used at the time has been replaced or rewritten, so any issue you're running into if very likely a different issue.

@BowsilAmee if this issue occurs every 24 hours, perhaps there's either a cron-tab running on the host, or perhaps NetworkManager is causing things to change (it's known to cause issues if it decides to change network configuration). Determining what the cause is just from your examples, would not be possible though; more information would be needed for that. Also be sure to try if curl -4 www.google.com works (i.e., force curl to use IPv4 resolution)

If you're running into this issue, and have ways to reproduce (and details to assist in finding the cause), please open a new issue, providing the information that's requested in the issue template.

Member

thaJeztah commented Jul 23, 2018

I'm locking the conversation on this issue; this issue is over 5 years old, and literally all code that was used at the time has been replaced or rewritten, so any issue you're running into if very likely a different issue.

@BowsilAmee if this issue occurs every 24 hours, perhaps there's either a cron-tab running on the host, or perhaps NetworkManager is causing things to change (it's known to cause issues if it decides to change network configuration). Determining what the cause is just from your examples, would not be possible though; more information would be needed for that. Also be sure to try if curl -4 www.google.com works (i.e., force curl to use IPv4 resolution)

If you're running into this issue, and have ways to reproduce (and details to assist in finding the cause), please open a new issue, providing the information that's requested in the issue template.

@moby moby locked and limited conversation to collaborators Jul 23, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.