I confirm that every second $ systemctl restart dnsmasq hangs
Also I confirm that removing squid resolved the situation.
I found that it does this: 1. /bin/sh /etc/init.d/dnsmasq systemd-stop-resolvconf 2. /bin/sh /etc/init.d/dnsmasq systemd-start-resolvconf
Both will call hooks like:
0 0 11642 11634 20 0 4364 660 wait S ? 0:00 \_ run-parts --arg=-a --arg=lo.dnsmasq /etc/resolvconf/update.d 0 0 11659 11642 20 0 4364 664 wait S ? 0:00 \_ run-parts /etc/resolvconf/update-libc.d 0 0 11672 11659 20 0 4504 704 wait S ? 0:00 \_ /bin/sh /etc/resolvconf/update-libc.d/squid 0 0 11673 11672 20 0 4504 1648 wait S ? 0:00 \_ /bin/sh /usr/sbin/invoke-rc.d squid reload 4 0 11691 11673 20 0 24888 1388 poll_s S ? 0:00 \_ systemctl reload squid.service
This is what actually times out - the squid hook.
The "systemctl reload squid.service" call seems to take too long every second time?!
A single "systemctl reload squid.service" for these seems to take ~100 seconds for me. OTOH a direct call to it is fast every time.
This needs to be debugged in detail, but seems well reproducible.
I confirm that every second
$ systemctl restart dnsmasq
hangs
Also I confirm that removing squid resolved the situation.
I found that it does this: stop-resolvconf start-resolvcon f
1. /bin/sh /etc/init.d/dnsmasq systemd-
2. /bin/sh /etc/init.d/dnsmasq systemd-
Both will call hooks like:
0 0 11642 11634 20 0 4364 660 wait S ? 0:00 \_ run-parts --arg=-a --arg=lo.dnsmasq /etc/resolvconf /update. d /update- libc.d /update- libc.d/ squid invoke- rc.d squid reload
0 0 11659 11642 20 0 4364 664 wait S ? 0:00 \_ run-parts /etc/resolvconf
0 0 11672 11659 20 0 4504 704 wait S ? 0:00 \_ /bin/sh /etc/resolvconf
0 0 11673 11672 20 0 4504 1648 wait S ? 0:00 \_ /bin/sh /usr/sbin/
4 0 11691 11673 20 0 24888 1388 poll_s S ? 0:00 \_ systemctl reload squid.service
This is what actually times out - the squid hook.
The "systemctl reload squid.service" call seems to take too long every second time?!
A single "systemctl reload squid.service" for these seems to take ~100 seconds for me.
OTOH a direct call to it is fast every time.
This needs to be debugged in detail, but seems well reproducible.