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@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?
mark
Maybe 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 wrote:
El Martes 02/02/2016, m.roth@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@palmtx.com.ar wrote:
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
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.
El Miércoles 03/02/2016, James Hogarth escribió:
On 2 Feb 2016 20:19, "Ricardo J. Barberis" ricardo@palmtx.com.ar wrote:
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
- 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.
Nice to know, I've only used systemd with CentOS 7 so I'm not terribly familiar with it, though I read a lot about it on Lennarts's blog.
The .include trick was from systemd 208 IIRC (from CentOS 7.0) but now we have systemd 219 (CentOS 7.2) so there's a lot of little new things to learn :)
You just need a systemctl daemon-reload after this not reenable.
The network targets situation is detailed (and the whys of it) in the
systemd.special man page.
Cheers,
De: "Ricardo J. Barberis" ricardo@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
-
James Hogarth -
m.roth＠5-cent.us -
Ricardo J. Barberis -
Sylvain CANOINE