This has been happening on a system that was upgraded from wheezy to jessie
Sometimes systemd starts the network and then tries to start things that
depend on the network (e.g. ntpdate, NFS client mounts) before DHCP has
obtained a lease.
Sometimes the boot completely stops and asks for root login
Sometimes it reaches the X login but if a user logs in, it throws them
out because their home is not mounted.
journalctl also shows errors from other processes that depend on the
network.
Here is the content of /etc/network/interfaces - it was working fine
with wheezy:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
#iface eth0 inet6 auto
iface eth0 inet6 dhcp
accept_ra 1
#allow-hotplug eth1
#iface eth1 inet dhcp
Am 04.07.2015 um 11:38 schrieb Daniel Pocock: Is home mounted via NFS? In the end this is a bug in ifupdown. It should ensure to block until the network has been configured successfully. If you change "allow-hotplug" to "auto", does that help?
/home is a local filesystem /home/username is on NFS I've changed it, I'll see how it behaves on subsequent reboots. The problem only occurs sporadically. Thanks for the fast feedback about this. Regards, Daniel
Am 04.07.2015 um 14:22 schrieb Daniel Pocock: Isn't ntpdate (*) started via an if-up.d hook i.e. not by systemd itself? Is /home mountend reliably by systemd? How is /home/username mounted? Via /etc/fstab, autofs, something else? Just trying to find out what exactly fails and what not. (*) As a side note: you might want to consider enabling systemd-timesyncd.service (and removing ntpdate). timesyncd is a very lightweight NTP client.
grep ntpdate /etc/init.d/* doesn't find anything. It is not run from cron or rc.local either. Looking at journalctl output, it looks like it tried to run ntpdate twice. I've copied the relevant events below: Jul 04 11:26:19 ntpdate[1182]: Can't find host ntp: Name or service not known (-2) Jul 04 11:26:19 ntpdate[1182]: no servers can be used, exiting Jul 04 11:26:19 daniel1 kernel: tg3 0000:02:00.0: irq 105 for MSI/MSI-X Jul 04 11:26:19 daniel1 kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Jul 04 11:26:19 daniel1 networking[1111]: Configuring network interfaces...done. Jul 04 11:26:19 daniel1 dhclient[1221]: Internet Systems Consortium DHCP Client 4.3.1 Jul 04 11:26:20 daniel1 dhclient[1221]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 Jul 04 11:26:20 mount[1268]: mount.nfs: Network is unreachable Jul 04 11:26:23 ntpd[1596]: ntpd 4.2.6p5@1.2349-o Fri Apr 10 19:04:04 UTC 2015 (1) Jul 04 11:26:23 ntp[1564]: Starting NTP server: ntpd. Jul 04 11:26:26 ifup[1199]: DHCPACK from 192.168.1.2 Jul 04 11:26:26 NetworkManager[1433]: <info> (eth1): preparing device Jul 04 11:26:26 NetworkManager[1433]: <info> (eth1): created default wired connection 'Wired connection 1' Jul 04 11:26:26 NetworkManager[1433]: <info> NetworkManager state is now CONNECTED_GLOBAL Jul 04 11:26:29 ntpdate[2157]: the NTP socket is in use, exiting Actually, /home is part of the root filesystem, it is not a separate filesystem. It always seems to mount the root filesystem successfully. Sometimes I have had systemd grumble trying to mount local filesystems twice on another machine but I haven't seen that happen on this one. Just /etc/fstab - it is very basic: 192.168.1.2:/home/daniel /home/daniel nfs rw,vers=3 0 2 Would this mean removing both the ntp and ntpdate packages? They are all configured to talk to an NTP server on 192.168.1.2
Hi, Am 04.07.2015 um 18:08 schrieb Daniel Pocock: systemd-timesyncd is only a (S)NTP client, it doesn't provider the server part. If you use NTP as a (local) NTP server, systemd-timesyncd can not replace. If you use NTP as a client only, you can uninstall both ntpdate and ntp and simply run systemctl enable systemd-timesyncd.service systemctl start systemd-timesyncd.service The default NTP servers are configured in /etc/systemd/timesyncd.conf. If you want to use your own, you can change the NTP= setting. See also man timesynd.conf. systemd-timesyncd works so well, that we decided to enable it by default for stretch. Regards, Michael
I wonder if you could use DNS SRV records to automate the
configuration too? e.g. trying to use the result of
DNS_DOMAIN=`domainname -d`
dig -t SRV _ntp._udp.${DNS_DOMAIN}
as the NTP server with no manual configuration.
Control: reassign -1 ifupdown I'm going to re-assign this to ifupdown. But my understanding is, that allow-hotplug is supposed to be *non*-blocking. So you won't get any guarantees during boot. If you want that, you are supposed to use "auto". I'll let Guus comment if he intends to address that (with the ifupdown-wait-online idea we discussed a while ago), or if he simply considers that expected behaviour. Regards, Michael
Laba diena, Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio. Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą. Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje. Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis. Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis: 1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais. 2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai. 3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus. Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas. Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia. ( Sąrašas prisegtas laiške excel faile ) Parašykite, kurias veiklas išsirinkote ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti Pagarbiai, Tadas Giedraitis Tel. nr. +37067881041
Hello, I had a very similar issue in Debian 9. A Debian 9 system that indeed has interface configured with allow-hotplug stanza in /etc/network/interfaces file, it fails to mount nfs shares (over nfs4.0). From the journal it seems that dhclient finishes **after** networking.service is activated. Networking.service is the one that calls ifup -a. Hence other services including nfs mounts are started early. But if auto ensxx is added to interfaces then ordering is correct (networking service is activated after ifup -a). I don't know if this is documented somewhere. But it is important to note! VG Debian 9.13 ifupdown 0.8.19 systemd 232-25+deb9u13 /etc/fstab 10.2.0.10:/data/oc-data /data/oc-data nfs timeo=20,_netdev 0 0 /etc/network/intefaces # The primary network interface allow-hotplug ens14 iface ens14 inet dhcp Logs excerpt from "journalctl -b" after a failed auto mount reboot allow-hotplug ens14 iface ens14 inet dhcp Μάρ 02 15:37:08 host1 systemd[1]: Started Raise network interfaces. Μάρ 02 15:37:10 host1 systemd[1]: Reached target Remote File Systems (Pre). Μάρ 02 15:37:10 host1 systemd[1]: Reached target RPC Port Mapper. Μάρ 02 15:37:10 host1 systemd[1]: Reached target Network is Online. Μάρ 02 15:37:10 host1 dhclient[439]: Copyright 2004-2016 Internet Systems Consortium Μάρ 02 15:37:10 host1 systemd[1]: Mounting /data/oc-data... Μάρ 02 15:37:11 host1 dhclient[439]: DHCPDISCOVER on ens14 to 255.255.255.255 port 67 interval 7 Μάρ 02 15:37:11 host1 dhclient[439]: DHCPREQUEST of 10.2.0.4 on ens14 to 255.255.255.255 port 67 Μάρ 02 15:37:11 host1 dhclient[439]: DHCPOFFER of 10.2.0.4 from 10.2.0.1 Μάρ 02 15:37:11 host1 dhclient[439]: DHCPACK of 10.2.0.4 from 10.2.0.1 Μάρ 02 15:37:11 host1 systemd[1]: data-oc\x2ddata.mount: Mount process exited, code=exited status=32 Μάρ 02 15:37:11 host1 systemd[1]: Failed to mount /data/oc-data.------- #allow-hotplug ens14 auto ens14 iface ens14 inet dhcp Μάρ 02 16:17:52 host1 systemd[1]: Starting Raise network interfaces.. Μάρ 02 16:17:56 host1 dhclient[455]: DHCPOFFER of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:56 host1 ifup[420]: DHCPOFFER of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:56 host1 dhclient[455]: DHCPACK of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:56 host1 ifup[420]: DHCPACK of 10.2.0.4 from 10.2.0.1 Μάρ 02 16:17:57 host1 ifup[420]: bound to 10.2.0.4 -- renewal in 2959 seconds. Μάρ 02 16:17:57 host1 systemd[1]: Started Raise network interfaces. Μάρ 02 16:17:57 host1 systemd[1]: Reached target Network. Μάρ 02 16:17:57 host1 systemd[1]: Reached target Network is Online. Μάρ 02 16:17:57 host1 systemd[1]: Mounting /data/oc-data... Μάρ 02 16:17:59 host1 systemd[1]: Mounted /data/oc-data.---- allow-hotplug ens14 auto ens14 iface ens14 inet dhcp Μάρ 02 16:28:23 host1 systemd[1]: Starting Raise network interfaces... Μάρ 02 16:28:25 host1 sh[375]: DHCPOFFER of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:25 host1 dhclient[422]: DHCPOFFER of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:25 host1 dhclient[422]: DHCPACK of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:25 host1 sh[375]: DHCPACK of 10.2.0.33 from 10.2.0.1 Μάρ 02 16:28:26 host1 dhclient[422]: bound to 10.2.0.33 -- renewal in 2976 seconds. Μάρ 02 16:28:26 host1 systemd[1]: Started Raise network interfaces. Μάρ 02 16:28:26 host1 systemd[1]: Reached target Network. Μάρ 02 16:28:26 host1 systemd[1]: Reached target Network is Online. Μάρ 02 16:28:26 host1 systemd[1]: Mounting /data/oc-data...