Control: fixed -1 234-1
Am 11.11.2017 um 00:33 schrieb Alex King:
> Looking at the code ("src/nspawn/nspawn.c" in v232), it appears that the
> existence of /usr/lib/systemd/resolv.conf, which exists on the
> problematic system, is triggering the problem.
Ok, I had another look. In v232, the check if resolved is active is
if (access("/usr/lib/systemd/resolv.conf", F_OK) >= 0) {
in later releases it is
if (access("/usr/lib/systemd/resolv.conf", F_OK) >= 0 &&
resolved_listening() > 0) {
The mere existence of resolve.conf is not sufficient to determine,
whether systemd-resolved is active or not. The only reason why other
systems are not afficient is the broken check which tests for the
resolv.conf in /usr (I've filed
https://github.com/systemd/systemd/issues/7302 for that). You simply
dodged that bullet by not having a /usr/lib/systemd/resolv.conf.
So, this particular stretch system of yours seems to be in a strange
state, if it has a /usr/lib/systemd/resolv.conf.
That said, there are two bugs in systemd-nspawn:
a/ the hard-coded path for the resolv.conf check
https://github.com/systemd/systemd/issues/7302
b/ not checking whether resolved is actually active
Fixed by
https://github.com/systemd/systemd/commit/7357272ed1c2c7a139c9ecbc8f3b8f63f71dd0b0
I'm thus marking this particular issue as fixed in v234
a/ still needs to be addressed.
Thanks for your detailed reply.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
