I occasionally hit this when transitioning to a VPN connection or shutting one down:
Mar 16 17:19:29 vfr NetworkManager[559]: <info> VPN connection 'cbeyond' (IP Config Get) complete. Mar 16 17:19:29 vfr NetworkManager[559]: <info> Policy set 'Built-in Ethernet' (em1) as default for IPv4 routing and DNS. Mar 16 17:19:29 vfr NetworkManager[559]: <info> DNS: starting dnsmasq... Mar 16 17:19:29 vfr dnsmasq[740]: exiting on receipt of SIGTERM Mar 16 17:19:29 vfr dnsmasq[31273]: failed to create listening socket for 127.0.0.1: Address already in use Mar 16 17:19:29 vfr dnsmasq[31273]: FAILED to start up Mar 16 17:19:30 vfr NetworkManager[559]: <info> VPN plugin state changed: started (4) Mar 16 17:19:30 vfr dbus[610]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Mar 16 17:19:30 vfr NetworkManager[559]: <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2)
It seems that NM kills the running dnsmasq and then restarts it. The new instance sometimes fails to bind because the old instance hasn't finished closing the port.
My work-around is to:
sudo systemctl start dnsmasq.service
when I notice the failure.
How can I eliminate this race?
Am 16.03.2013 23:37, schrieb Garry T. Williams:
I occasionally hit this when transitioning to a VPN connection or shutting one down:
Mar 16 17:19:29 vfr NetworkManager[559]: <info> VPN connection 'cbeyond' (IP Config Get) complete. Mar 16 17:19:29 vfr NetworkManager[559]: <info> Policy set 'Built-in Ethernet' (em1) as default for IPv4 routing and DNS. Mar 16 17:19:29 vfr NetworkManager[559]: <info> DNS: starting dnsmasq... Mar 16 17:19:29 vfr dnsmasq[740]: exiting on receipt of SIGTERM Mar 16 17:19:29 vfr dnsmasq[31273]: failed to create listening socket for 127.0.0.1: Address already in use Mar 16 17:19:29 vfr dnsmasq[31273]: FAILED to start up Mar 16 17:19:30 vfr NetworkManager[559]: <info> VPN plugin state changed: started (4) Mar 16 17:19:30 vfr dbus[610]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Mar 16 17:19:30 vfr NetworkManager[559]: <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2)It seems that NM kills the running dnsmasq and then restarts it. The new instance sometimes fails to bind because the old instance hasn't finished closing the port.
My work-around is to:
sudo systemctl start dnsmasq.servicewhen I notice the failure. How can I eliminate this race?
systemd supports auto-restart of services and nobody knows why it is not used as default while i have it for ANY service since Fedora 15 in production use
yes, it's a workaround but it should work without user interaction and since i avoid NetworkManager and use the classical "network.service" with a static config nor have installed NM on anymachine.............
* FIRST: systemctl disable dnsmasq.service * create /etc/systemd/system/dnsmasq.service * systemctl daemon-reload * systemctl enable dnsmasq.service * systemctl restart dnsmasq.service
[root@proxy:~]$ cat /etc/systemd/system/dnsmasq.service [Unit] Description=DNS caching server After=network.target network.service
[Service] Type=forking EnvironmentFile=-/etc/sysconfig/network ExecStart=/usr/sbin/dnsmasq Restart=always RestartSec=1
[Install] WantedBy=multi-user.target
On 3-16-13 23:52:39 Reindl Harald wrote:
Am 16.03.2013 23:37, schrieb Garry T. Williams:
It seems that NM kills the running dnsmasq and then restarts it. The new instance sometimes fails to bind because the old instance hasn't finished closing the port.
My work-around is to:
sudo systemctl start dnsmasq.servicewhen I notice the failure. How can I eliminate this race?
systemd supports auto-restart of services and nobody knows why it is not used as default while i have it for ANY service since Fedora 15 in production use
yes, it's a workaround but it should work without user interaction and since i avoid NetworkManager and use the classical "network.service" with a static config nor have installed NM on anymachine.............
Yes. This is a better work-around. Thanks for the suggestion.
-
Garry Williams -
Reindl Harald