[systemd-devel] /etc/resolv.conf link in container

[Johannes Ernst]

I have a root filesystem in directory foo/
It has symlink
foo/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

When I’m booting the container:
sudo systemd-nspawn --directory foo --boot

I’m getting:
Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many levels of symbolic links

This message makes very little sense to me. Why is a copy necessary? and is that indeed /etc/resolv.conf or foo/etc/resolv.conf?

If I boot with -n, I don’t seem to get the error.

Puzzled.



Johannes.

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst

Post by Johannes Ernst
I have a root filesystem in directory foo/
It has symlink
foo/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
sudo systemd-nspawn --directory foo --boot
Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many levels of symbolic links
This message makes very little sense to me. Why is a copy necessary? and is that indeed /etc/resolv.conf or foo/etc/resolv.conf?
If I boot with -n, I don’t seem to get the error.

If you pass --private-network / -n, then we never touch resolv.conf.
In all other cases, we copy resolv.conf from the host into the
container. We usually assume that if your container runs in the same
network as the host, then the container must also use the DNS features
of the host.

The error code of "Too many levels of symbolic links" is ELOOP. This
is returned by open() in many cases. In this example, it is returned
because we passed O_NOFOLLOW to open(), but the final part of the path
is a symlink. In that case, the kernel returns ELOOP to tell us that
we're dealing with a symlink.

Maybe Lennart or Tom have some comments on that? Your example use-case
(resolved in the container, even with shared network namespace) looks
valid, though odd. I mean, what's the reason not to use "-n"? Anyway,
maybe we can deal with ELOOP in setup_resolv_conf() and just print a
big fat warning?
But lets people who know that stuff comment first..

Thanks
David

[Johannes Ernst]

Post by David Herrmann
Hi
On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst

Post by Johannes Ernst
I have a root filesystem in directory foo/
It has symlink
foo/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
sudo systemd-nspawn --directory foo --boot
Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many levels of symbolic links
This message makes very little sense to me. Why is a copy necessary? and is that indeed /etc/resolv.conf or foo/etc/resolv.conf?
If I boot with -n, I don’t seem to get the error.

If you pass --private-network / -n, then we never touch resolv.conf.
In all other cases, we copy resolv.conf from the host into the
container. We usually assume that if your container runs in the same
network as the host, then the container must also use the DNS features
of the host.
The error code of "Too many levels of symbolic links" is ELOOP. This
is returned by open() in many cases. In this example, it is returned
because we passed O_NOFOLLOW to open(), but the final part of the path
is a symlink. In that case, the kernel returns ELOOP to tell us that
we're dealing with a symlink.
Maybe Lennart or Tom have some comments on that? Your example use-case
(resolved in the container, even with shared network namespace) looks
valid, though odd. I mean, what's the reason not to use "-n”?

Well, if there isn’t a reason, why does the mode exist?

Post by David Herrmann
Anyway,
maybe we can deal with ELOOP in setup_resolv_conf() and just print a
big fat warning?
But lets people who know that stuff comment first..
Thanks
David

[Lennart Poettering]

Post by Johannes Ernst

Post by David Herrmann
If you pass --private-network / -n, then we never touch resolv.conf.
In all other cases, we copy resolv.conf from the host into the
container. We usually assume that if your container runs in the same
network as the host, then the container must also use the DNS features
of the host.
The error code of "Too many levels of symbolic links" is ELOOP. This
is returned by open() in many cases. In this example, it is returned
because we passed O_NOFOLLOW to open(), but the final part of the path
is a symlink. In that case, the kernel returns ELOOP to tell us that
we're dealing with a symlink.
Maybe Lennart or Tom have some comments on that? Your example use-case
(resolved in the container, even with shared network namespace) looks
valid, though odd. I mean, what's the reason not to use "-n”?

Well, if there isn’t a reason, why does the mode exist?

-n is only fun to use if you have networkd in the container on the
host right now, since only them currently ship the magic defaults
that make networking just work if you use -n. With other network
management solutions it's a much more manual process, and hence it
might be easier to avoid -n for them...

Lennart

[Lennart Poettering]

Post by David Herrmann
Hi
On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst

Post by Johannes Ernst
I have a root filesystem in directory foo/
It has symlink
foo/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
sudo systemd-nspawn --directory foo --boot
Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many levels of symbolic links
This message makes very little sense to me. Why is a copy necessary? and is that indeed /etc/resolv.conf or foo/etc/resolv.conf?
If I boot with -n, I don’t seem to get the error.

If you pass --private-network / -n, then we never touch resolv.conf.
In all other cases, we copy resolv.conf from the host into the
container. We usually assume that if your container runs in the same
network as the host, then the container must also use the DNS features
of the host.
The error code of "Too many levels of symbolic links" is ELOOP. This
is returned by open() in many cases. In this example, it is returned
because we passed O_NOFOLLOW to open(), but the final part of the path
is a symlink. In that case, the kernel returns ELOOP to tell us that
we're dealing with a symlink.
Maybe Lennart or Tom have some comments on that? Your example use-case
(resolved in the container, even with shared network namespace) looks
valid, though odd. I mean, what's the reason not to use "-n"? Anyway,
maybe we can deal with ELOOP in setup_resolv_conf() and just print a
big fat warning?
But lets people who know that stuff comment first..

I have now prepped this PR:

https://github.com/systemd/systemd/pull/291

It suppresses the ELOOP (and also EROFS) in this case. Please review.

Lennart