[systemd-bugs] [Bug 85555] New: systemd-resolve daemon creates invalid resolv.conf
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Oct 28 06:10:03 PDT 2014
https://bugs.freedesktop.org/show_bug.cgi?id=85555
Bug ID: 85555
Summary: systemd-resolve daemon creates invalid resolv.conf
Product: systemd
Version: unspecified
Hardware: x86-64 (AMD64)
URL: https://gist.github.com/xorpaul/764fd9e3d775ab3c2c7c
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: general
Assignee: systemd-bugs at lists.freedesktop.org
Reporter: xorpaul at gmail.com
QA Contact: systemd-bugs at lists.freedesktop.org
My CoreOS VM is supposed to work with DHCP, but creates an invalid resolv.conf
and does not send its hostname to the DHCP server, which prevents the DNS
resolution of the VM's FQDN from working.
```
# systemctl --version
systemd 215
-PAM -AUDIT -SELINUX +IMA -SYSVINIT +LIBCRYPTSETUP -GCRYPT -ACL -XZ +SECCOMP
-APPARMOR
```
```
# cat /etc/lsb-release
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=444.5.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 444.5.0"
```
Hostname from the /var/lib/coreos-install/user_data works, but no domain is
available:
```
# hostname
vm-coreos
# hostname -f
hostname: Unknown host
```
The FQDN of this VM should be vm-cores.test.lan, but the systemd-resolved adds
all *search* domains to the actual domain and doesn't add any search domains at
all:
```
# cat /etc/resolv.conf
# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.
domain test.lan foo.lan bar.domain kamenzu.local
nameserver 1.2.3.4
nameserver 1.2.3.5
```
```
# journalctl -l | awk 'BEGIN{IGNORECASE=1} /dhcp/ || /network/'
Oct 28 11:21:31 localhost systemd[1]: Starting Network Time Service...
Oct 28 11:21:31 localhost systemd[1]: Started Network Time Service.
Oct 28 11:21:31 localhost systemd[1]: Starting Network Service...
Oct 28 11:21:32 localhost systemd-networkd[480]: lo : gained
carrier
Oct 28 11:21:32 localhost systemd[1]: Started Network Service.
Oct 28 11:21:32 localhost systemd[1]: Starting Network.
Oct 28 11:21:32 localhost systemd[1]: Reached target Network.
Oct 28 11:21:32 localhost systemd[1]: Starting Network Name Resolution...
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0 : link
configured
Oct 28 11:21:32 localhost systemd-networkd[480]: lo : link
configured
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0 : gained
carrier
Oct 28 11:21:32 localhost systemd[1]: Started Network Name Resolution.
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0 : DHCPv4
address 1.9.3.3/22 via 1.2.3.1
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0 : link
configured
Oct 28 11:21:33 vm-andpaul-coreos coreos-cloudinit[460]: 2014/10/28 11:21:33
Wrote file /etc/systemd/network/20-dhcp.network to filesystem
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd] +job
init_networkdriver()
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd.init_networkdriver()]
creating new bridge for docker0
Oct 28 11:21:34 vm-andpaul-coreos systemd-networkd[480]: docker0 : link
configured
Oct 28 11:21:34 vm-andpaul-coreos systemd-networkd[480]: docker0 :
gained carrier
Oct 28 11:21:34 vm-andpaul-coreos systemd-networkd[480]: docker0 : lost
carrier
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd.init_networkdriver()]
getting iface addr
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd] -job
init_networkdriver() = OK (0)
Oct 28 11:35:45 vm-andpaul-coreos update_engine[467]:
[1028/113545:ERROR:omaha_request_action.cc(629)] Omaha request network transfer
failed.
```
If I use dhcpd to get a new IP from the DHCP server:
```
# dhcpcd eth0
dhcpcd[853]: version 6.2.0 starting
dhcpcd[853]: DUID 00:01:00:01:1b:e2:3f:d9:00:1a:4a:94:32:ba
dhcpcd[853]: eth0: IAID 4a:94:32:ba
dhcpcd[853]: eth0: soliciting an IPv6 router
dhcpcd[853]: eth0: soliciting a DHCP lease
dhcpcd[853]: eth0: offered 1.9.3.8 from 172.19.64.36
dhcpcd[853]: eth0: leased 1.9.3.8 for 3600 seconds
dhcpcd[853]: eth0: adding route to 1.9.3.0/22
dhcpcd[853]: eth0: adding default route via 1.9.3.1
/lib/dhcpcd/dhcpcd-run-hooks: line 122: /etc/ntp.conf: Read-only file system
dhcpcd[853]: forked to background, child pid 920
```
I get a correct and valid resolv.conf:
```
# cat /etc/resolv.conf
# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
domain test.lan
search foo.lan bar.domain kamenzu.local
nameserver 1.2.3.4
nameserver 1.2.3.5
# /etc/resolv.conf.tail can replace this line
```
and more importantly the FQDN can be resolved from the outside:
```
host vm-coreos.test.lan
vm-coreos.test.lan has address 1.9.3.8
```
hostname -f still does not work:
```
# hostname -f
hostname: Unknown host
```
Added both lease files:
correct one from dhcpd:
```
# cat /run/dhcpcd/resolv.conf/eth0
# Generated by dhcpcd from eth0
domain test.lan
search foo.lan bar.domain kamenzu.local
nameserver 172.19.254.1
nameserver 172.19.255.1
```
invalid domain name from systemd:
```
# cat /run/systemd/netif/leases/2
# This is private data. Do not parse.
ADDRESS=1.9.3.3
NETMASK=255.255.252.0
ROUTER=1.9.3.1
SERVER_ADDRESS=1.2.3.1
NEXT_SERVER=1.2.3.7
DNS=1.2.3.4 1.2.3.5
NTP=1.2.7.4 1.2.7.5
DOMAINNAME=test.lan foo.lan bar.domain kamenzu.local
```
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20141028/37600597/attachment.html>
More information about the systemd-bugs
mailing list