I go to a lot of trouble to NOT mount NFS at boot because many test systems here are often down and I don't want to timeout when trying to mount things.
I can still mount things manually when I need them, but now systemd screws up my life by saying "Ah-HA! Here's an NFS mount! I'll make a unit for it so I can spend 10 minutes timing out when the poor fool tries to reboot after that NFS server goes down!"
How do I make it stop? How do I get systemd to leave NFS mounts utterly and completely alone? I DO NOT CARE if they are properly unmounted by crossing all I's and dotting all T's. I just want to frigging REBOOT!
Tom Horsley wrote:
How do I make it stop? How do I get systemd to leave NFS mounts utterly and completely alone? I DO NOT CARE if they are properly unmounted by crossing all I's and dotting all T's. I just want to frigging REBOOT!
Add "noauto" to the mount options of the NFS share in your fstab.
Michael Cronenworth wrote:
Tom Horsley wrote:
How do I make it stop? How do I get systemd to leave NFS mounts utterly and completely alone? I DO NOT CARE if they are properly unmounted by crossing all I's and dotting all T's. I just want to frigging REBOOT!
Add "noauto" to the mount options of the NFS share in your fstab.
Sorry, I see you're asking about shutdown time. There are no shutdown options for mounts. You might try a custom unit file that forces an umount on shutdown, but that's about as best as you could do. You could also try adding "x-systemd.device-timeout=10" to reduce the timeout to 10 seconds (or less).
If you want network shares that behave better when shares are not available I suggest looking at GlusterFS.
On Wed, 15 Jan 2014 13:27:26 -0600 Michael Cronenworth wrote:
Add "noauto" to the mount options of the NFS share in your fstab.
They do all have noauto, the problem is that when I manually mount it after the system is up, systemd "helpfully" creates a .mount unit dynamically which then causes it to wait forever when I try to reboot later and that test server happens to be down.
On Jan 15, 2014 12:46 PM, "Tom Horsley" horsley1953@gmail.com wrote:
On Wed, 15 Jan 2014 13:27:26 -0600 Michael Cronenworth wrote:
Add "noauto" to the mount options of the NFS share in your fstab.
They do all have noauto, the problem is that when I manually mount it after the system is up, systemd "helpfully" creates a .mount unit dynamically which then causes it to wait forever when I try to reboot later and that test server happens to be down. --
I'm not clear on why the creation of a mount unit is the culprit here. Hasn't of always been the case that filesystems are unmounted during shutdown? Hasn't unmounting of unavailable NFS mounts always hung until timeout?
--Pete
On Wed, 15 Jan 2014 12:55:19 -0700 Pete Travis wrote:
I'm not clear on why the creation of a mount unit is the culprit here. Hasn't of always been the case that filesystems are unmounted during shutdown? Hasn't unmounting of unavailable NFS mounts always hung until timeout?
Not when it was dead easy to change the init script to stick an '&' on the end of the umount command, it didn't wait then, and even when you forgot to do that, it didn't take hours to timeout like systemd does.
But of course, according to the devs, it is a common myth that systemd isn't scriptable, so obviously there is a simple way to change this behavior, right? (Though I've been poking through the source and it sure looks to me like the only way to change this is to rebuild from source and check fstype for "nfs" to prevent it from trying forever to umount it).
Tom Horsley wrote:
Not when it was dead easy to change the init script to stick an '&' on the end of the umount command, it didn't wait then, and even when you forgot to do that, it didn't take hours to timeout like systemd does.
But of course, according to the devs, it is a common myth that systemd isn't scriptable, so obviously there is a simple way to change this behavior, right? (Though I've been poking through the source and it sure looks to me like the only way to change this is to rebuild from source and check fstype for "nfs" to prevent it from trying forever to umount it).
Please see my second e-mail.
https://lists.fedoraproject.org/pipermail/users/2014-January/445481.html
2014/1/15 Tom Horsley horsley1953@gmail.com
Not when it was dead easy to change the init script to stick an '&' on the end of the umount command, it didn't wait then, and even when you forgot to do that, it didn't take hours to timeout like systemd does.
But of course, according to the devs, it is a common myth that systemd isn't scriptable, so obviously there is a simple way to change this behavior, right? (Though I've been poking through the source and it sure looks to me like the only way to change this is to rebuild from source and check fstype for "nfs" to prevent it from trying forever to umount it).
Try to add the mount option "_netdev", it should schedule the mount/umount after/before the network.
On Wed, 15 Jan 2014 23:13:34 +0100 Juan Orti Alcaine wrote:
Try to add the mount option "_netdev", it should schedule the mount/umount after/before the network.
That does nothing useful, it is still going to try and unmount it. I want it to ignore it utterly because the umount will take forever.
On 01/16/14 06:24, Tom Horsley wrote:
On Wed, 15 Jan 2014 23:13:34 +0100 Juan Orti Alcaine wrote:
Try to add the mount option "_netdev", it should schedule the mount/umount after/before the network.
That does nothing useful, it is still going to try and unmount it. I want it to ignore it utterly because the umount will take forever.
Well, you could always make a wrapper around a shutdown command and use "umount -f" as in "force".
Well, you could always make a wrapper around a shutdown command and use "umount -f" as in "force".
Something like that might work if this bugfix has made it into the current kernel (it probably has, we're on 3.12 now):
https://bugzilla.redhat.com/show_bug.cgi?id=980088
But what I'd really need is a new systemd unit that umount depends on that could run first and umount -f all the NFS filesystems in the background, then umount -l them for good measure (because I've seen -f take forever to timeout as well :-). That way I wouldn't need an alias for every possible shutdown command.
On 01/16/14 07:09, Tom Horsley wrote:
Well, you could always make a wrapper around a shutdown command and use "umount -f" as in "force".
Something like that might work if this bugfix has made it into the current kernel (it probably has, we're on 3.12 now):
https://bugzilla.redhat.com/show_bug.cgi?id=980088
But what I'd really need is a new systemd unit that umount depends on that could run first and umount -f all the NFS filesystems in the background, then umount -l them for good measure (because I've seen -f take forever to timeout as well :-). That way I wouldn't need an alias for every possible shutdown command.
Well, I suppose you could always work on your own systemd unit to do that. I certainly wouldn't want it as a default on any of my systems. I've got a fairly old/slow NFS server on my network and when large transfers are going on it can appear to be hung. I'd be concerned that doing this as a default action would result in transfers being terminated and data being lost/corrupted.
Unless there are others than yourself using the system you wouldn't need an alias for every possible shutdown command. :-) :-)
On Wed, Jan 15, 2014 at 9:54 PM, Michael Cronenworth mike@cchtml.com wrote:
Please see my second e-mail.
https://lists.fedoraproject.org/pipermail/users/2014-January/445481.html
You seem to be missing the point. With SysV init, you could just edit the appropriate file in /etc/init.d and tell it not to try shutting this service down when rebooting. What's wanted here is not some way to forcibly umount network filesystems at reboot time, or an alternative filesystem to try. What Tom appeared to be asking for was a way to tell systemd "don't even attempt to umount these".
My best suggestion is:
alias reboot="echo u > /proc/sysrq-trigger; sleep 1; echo b > /proc/sysrq-trigger"
Brute force and ignorance, but it should achieve what you want (assuming you don't have anything else on the system that needs shutting down cleanly).
Tet
-
Ed Greshko -
Juan Orti Alcaine -
Michael Cronenworth -
Pete Travis -
Tethys -
Tom Horsley