In the last month, we've discovered a new, ahhhh, "feature" in the
version
of the version of NFS with CentOS 7: on startup, if it cannot resolve a
given host, it dies. It does not continue on up, with all the other hosts
it's exporting to, and just log a message.
Is there a workaround, or a configuration, to change this "fail on
unresolved host" behaviour?
mark
El Martes 02/02/2016, m.roth at 5-cent.us escribi?:> In the last month, we've discovered a new, ahhhh, "feature" in the version > of the version of NFS with CentOS 7: on startup, if it cannot resolve a > given host, it dies. It does not continue on up, with all the other hosts > it's exporting to, and just log a message. > > Is there a workaround, or a configuration, to change this "fail on > unresolved host" behaviour? > > markMaybe NFS should wait for the network to be up? I had a similar problem with an nginx binded to a specific IP, it didn't start because the interface wasn't yet up, so I had to make a new unit and put this inside (/etc/systemd/system/nginx.service): <code> .include /usr/lib/systemd/system/nginx.service [Unit] After=network.target remote-fs.target nss-lookup.target network-online.target </code> The After line is the important one, I copied it from /usr/lib/systemd/system/nginx.service and added "network-online.target" at the end. After making your changes, be sure to reenable the service so it takes your new unit, e.g.: # systemctl reenable nginx.service It worked for me, maybe it works for you? Cheers, -- Ricardo J. Barberis Usuario Linux N? 250625: http://counter.li.org/ Usuario LFS N? 5121: http://www.linuxfromscratch.org/ Senior SysAdmin / IT Architect - www.DonWeb.com
Ricardo J. Barberis wrote:> El Martes 02/02/2016, m.roth at 5-cent.us escribi?: >> In the last month, we've discovered a new, ahhhh, "feature" in the >> version of the version of NFS with CentOS 7: on startup, if it >> cannot resolve a given host, it dies. It does not continue on up, >> with all the other hosts it's exporting to, and just log a message. >> >> Is there a workaround, or a configuration, to change this "fail on >> unresolved host" behaviour? > > Maybe NFS should wait for the network to be up?<snip> Good thought, but no - this was an issue where the servers names were changed, or moved - I disremember which. And it came up originally, because we have one server that's accessed all over campus, at other Institutes, and some people leave, and their machines go away, repurposed or surplused, but they're still listed on our exports file. mark
On 2 Feb 2016 20:19, "Ricardo J. Barberis" <ricardo at palmtx.com.ar> wrote:> because the interface wasn't yet up, so I had to make a new unit and putthis> inside (/etc/systemd/system/nginx.service): > > <code> > .include /usr/lib/systemd/system/nginx.service > > [Unit] > After=network.target remote-fs.target nss-lookup.targetnetwork-online.target> </code> > > > The After line is the important one, I copied it from > /usr/lib/systemd/system/nginx.service and added "network-online.target" > at the end. > > After making your changes, be sure to reenable the service so it takesyour> new unit, e.g.: > > # systemctl reenable nginx.service > >1) Don't use .include as that's not recommended and deprecated behaviour. Make an override snippet in /etc/systemd/system/nginx.service.d called custom.conf or network.conf or something. This has the benefit as well of working nicely with systemctl cat and systemd-delta. 2) You just need a systemctl daemon-reload after this not reenable. 3) The network targets situation is detailed (and the whys of it) in the systemd.special man page.
> De: "Ricardo J. Barberis" <ricardo at palmtx.com.ar> > [Unit] > After=network.target remote-fs.target nss-lookup.target network-online.target > </code> > > > The After line is the important one, I copied it from > /usr/lib/systemd/system/nginx.service and added "network-online.target" > at the end. > > After making your changes, be sure to reenable the service so it takes your > new unit, e.g.: > > # systemctl reenable nginx.service > > > It worked for me, maybe it works for you?On my systems, I saw that network.target was not started, because no service required it ("After=foo" is totally useless if there isn't any "Require=foo" too... Mwokay, why not...). I just added a symlink to force network.target to start, and the ordering problem is solved : /etc/systemd/system/multi-user.target.wants/network.target -> /usr/lib/systemd/system/network.target That link avoids modifying the configuration of _all_ the services needing a fully working network (ssh, web, mail, snmp, and so on) with a crappy, but easy-to-deploy, one-liner like this (no, I'm not ashamed) : # for fic in $(grep -rl "After=.*network.target" /lib/systemd/system | cut -d/ -f5 | grep -v "network-online.target") ; do [ ! -d "/etc/systemd/system/${fic}.d" ] && mkdir "/etc/systemd/system/${fic}.d" ; echo -e "[Unit]\nAfter=network-online.target" > "/etc/systemd/system/${fic}.d/local-network-online.conf" ; done && systemctl daemon-reload By the way, congratulations to the genius who decided to name one of the files "-.slice"... Yes, a filename beginning by a hyphen. I suppose anybody here understands why it's probably one of the worst ideas he never had. Sylvain. Pensez ENVIRONNEMENT : n'imprimer que si ncessaire