Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
On Thu, Sep 3, 2020 at 3:02 PM Michael Biebl wrote: > > Hi Dan Hi Michael > > Am 03.09.20 um 20:42 schrieb Dan Streetman: > > On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl wrote: > 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. > > > Now I'm confused. > What my patch does (and which has been applied to resolvconf) is to drop > PathExists (instead the service is activated via > [Install] > WantedBy=systemd-resolved.service > ) > The PathChanged= bit has always been there. My patch did not add this. Sorry my bad, you are right, both PathExists= and PathChanged= were there before, and just PathChanged= now. Looks correct! > > Michael >
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
Hi Dan Am 03.09.20 um 20:42 schrieb Dan Streetman: > On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl wrote: 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. Now I'm confused. What my patch does (and which has been applied to resolvconf) is to drop PathExists (instead the service is activated via [Install] WantedBy=systemd-resolved.service ) The PathChanged= bit has always been there. My patch did not add this. Michael signature.asc Description: OpenPGP digital signature
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl 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?= > 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
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
Am 17.08.20 um 10:41 schrieb Michael Biebl: > 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. Btw, I'll add a versioned Breaks: resolvconf (<< 1.83) to systemd, assuming the next resolvconf upload will have a fix for this issue signature.asc Description: OpenPGP digital signature
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
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?= 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 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 diff --git a/debian/resolvconf.resolvconf-pull-resolved.path b/debian/resolvconf.resolvconf-pull-resolved.path index 9ccd05e..1f1cdf9 100644 --- a/debian/resolvconf.resolvconf-pull-resolved.path +++ b/debian/resolvconf.resolvconf-pull-resolved.path @@ -1,6 +1,5 @@ [Path] PathChanged=/run/systemd/resolve/stub-resolv.conf -PathExists=/run/systemd/resolve/stub-resolv.conf [Install] WantedBy=systemd-resolved.service diff --git a/debian/resolvconf.resolvconf-pull-resolved.service b/debian/resolvconf.resolvconf-pull-resolved.service index 109c462..e5d8d25 100644 --- a/debian/resolvconf.resolvconf-pull-resolved.service +++ b/debian/resolvconf.resolvconf-pull-resolved.service @@ -1,7 +1,11 @@ [Unit] ConditionPathExists=/run/resolvconf/enable-updates ConditionFileIsExecutable=/sbin/resolvconf +After=systemd-resolved.service [Service] Type=oneshot ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | grep -v edns0 | /sbin/resolvconf -a systemd-resolved' + +[Install] +WantedBy=systemd-resolved.service signature.asc Description: OpenPGP digital signature
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
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. Cheers, Thomas Mühlbacher
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
I was also hit by this bug. The rate of logspam caused by the failure message was so intense that my laptop's SATA SSD was filling up at hundreds of MiB per minute. The I/O flood made everything slow down; login barely worked, bash-completion tabbing took 5-10 s, and figuring out which process(es) to kill before space runs out was a race against time that I nearly lost. It's been a long time since I last experienced a bug that demanded a similarly urgent and decisive user response as this. In my opinion this is a serious one.
Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2
Package: resolvconf Version: 1.82 Since `systemd` version 246-2, systems using `systemd-resolved` fail to reach the `default.target` if `resolvconf` is also installed. Steps to reproduce the error in a sysroot (`less` and `bash-completion` are just for comfort in debugging/reading logs): ```shell # debootstrap --variant minbase sid sid # systemd-nspawn --directory sid # apt update # apt install resolvconf systemd less bash-completion # systemctl enable systemd-networkd # systemctl enable systemd-resolved # exit # systemd-nspawn --directory sid --boot ``` With the last command `init` will try to start `resolvconf-pull-resolved.service` endlessly and not reach the `default.target`. At this point, you may no longer be able to read `systemd-nspawn`'s info in your terminal so keep in mind: > Press ^] three times within 1s to kill container. The error messages: ``` ... [FAILED] Failed to start resolvconf-pull-resolved.service. See 'systemctl status resolvconf-pull-resolved.service' for details. [FAILED] Failed to start resolvconf-pull-resolved.service. See 'systemctl status resolvconf-pull-resolved.service' for details. [FAILED] Failed to start resolvconf-pull-resolved.service. See 'systemctl status resolvconf-pull-resolved.service' for details. [FAILED] Failed to start resolvconf-pull-resolved.service. See 'systemctl status resolvconf-pull-resolved.service' for details. [FAILED] Failed to start resolvconf-pull-resolved.service. See 'systemctl status resolvconf-pull-resolved.service' for details. [FAILED] Failed to start resolvconf-pull-resolved.service. See 'systemctl status resolvconf-pull-resolved.service' for details. ... ``` This also happens on physical machines, leaving some of mine unbootable currently. :( Unfortunately I am not completely sure why the service fails as I am not familiar enough with it. This is my first Debian bug report so I hope I did it correctly. Should this bug somehow tag the Debian systemd team as well, since technically an update to the `systemd` package introduced it? A solution may be to just not install `resolvconf` but it's in the `Recommends` of a lot of other packages so it will be installed on many systems that might use `resolved`, which is already a part of the `systemd` package. Cheers, Thomas Mühlbacher
