Comment 7 for bug 1761096

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

OK, I've spent some time investigating this one, so I decided to post my progress here. Unfortunately I don't have a full fix yet, but I managed to find some interesting pointers related to systemd.

First of all, I confirmed what Christian and Andreas were seeing: the problem happens on every second "systemctl start dnsmasq.service"; squid takes 30 seconds to restart regardless of dnsmasq/resolvconf (this is still true nowadays, with groovy); nss-lookup.target fails to start on xenial, but does start on bionic; the issue doesn't seem to happen on bionic.

As for the systemd bits I mentioned, I found these issues:

- https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1417010
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777113

The good news is that they are really similar to what we're experiencing here, even though our problem doesn't seem to be cirular dependencies on systemd service files. The bad news is that the fix proposed by Martin Pitt (the last one, that ended up landing) is already available on xenial.

One of the suggested fixes was to add a "--no-block" on /usr/sbin/invoke-rc.d's "systemctl reload" command. I did that, and it obviously "solves" the issue, although I'm not confident that it's the proper fix for this.

Something that caught my attention is the fact that the process that is hung is actually the "systemctl reload squid", and not squid itself. I verified that "/etc/init.d/squid reload" actually exits successfully, but for some reason "systemctl reload squid" keeps waiting. With what I know so far, I feel inclined to say that this is a systemd issue, and not a dnsmasq/squid/resolvconf one (of course, we can talk about squid's 30-second restart, but that's orthogonal).

I'll let you know when I have more data (or hopefully a fix). Meanwhile, I'd appreciate comments/feedback, if you have any.