On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl <bi...@debian.org> wrote: > > Control: severity -1 serious > Control: tags -1 + patch > > Hi everyone, > > I think the effects of this issue are severe enough, that it needs to be > fixed for bullseye. In other words, it should be RC > > On Sat, 08 Aug 2020 13:13:44 +0200 =?utf-8?q?Thomas_M=C3=BChlbacher?= > <tmuehlbac...@posteo.net> wrote: > > I noticed that there were already two related bugreports, with Michael > > Biebl providing a solution for the issue: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906 > > > > And to a lesser degree this one, I suppose: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968009 > > > > I tried the container setup again with `PathExists=` dropped from > > `resolvconf-pull-resolved.path` and it stops the errors from occurring, > > however I did not verify that this way the service still does what it's > > supposed to. > > #967906 and the related upstream bug report > https://github.com/systemd/systemd/issues/16669 have more context. > > In short: PathExists in systemd v246 changed its behaviour to actually > match the documentation. > For resolvconf-pull-resolved.service that means, it's continuously > started over and over again. > > Afaics, the simplest solution, is to simply drop > > PathExists=/run/systemd/resolve/stub-resolv.conf > > and instead add a > > [Install] > WantedBy=systemd-resolved.service > > > to resolvconf-pull-resolved.service and also add a > After=systemd-resolved.service
It looks like resolvconf's resolvconf-pull-resolved.path has been updated to use PathChanged instead. That should fix the constant loop, though I'm not sure if it is optimal, as I vaguely remember someone complaining that systemd-resolved rewrites stub-resolv.conf often, and IIUC PathChanged= triggers on inotify IN_CLOSE_WRITE so it would trigger each time systemd-resolved opened (for write) and closed the file. Although I have not actually looked into the code, so maybe it's fine. In general I've tried to stay away from resolvconf as the integration with resolved has been a bit painful, and I think xnox is in the process of trying to fix that up. I do tag any LP bugs that I notice relate to resolved/resolvconf integration/interaction with the 'resolved-resolvconf' tag: https://bugs.launchpad.net/bugs/+bugs?field.tag=resolved-resolvconf > > I've attached a prospective patch. > > Dan, Dimitri, would welcome your feedback here, since most of the > resolvconf/resolved integration is seemingly coming from you. > > > Regards, > Michael
