http://bugzilla.suse.com/show_bug.cgi?id=911986 Martin Vidner changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High Status|NEW |CONFIRMED Summary|yast2-nfs-client with |[yast2-nfs-client] needs |nfs-client 1.3.1 |adapting to nfs-client | |1.3.1: systemd services -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 --- Comment #1 from Tomáš Chvátal --- This issue even tho affecting Factory is actually able to improve behaviour for our SLE 12 too. There are more than 10 (currently 5 on Standa, we duped some against each other) mount issues like "nfs starts before network devices" or "nfs won't autoremount" caused by not using the proper systemd services and their dependencies. For the bug info search in bugzie for "nfs fails to mount" "nfsserver automount" and similar. When this is included it would be one of the prominent candidates for sp1 inclusion. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 Martin Vidner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tchvatal@suse.com --- Comment #2 from Martin Vidner --- Tomas, I don't know what you mean with SLE 12. As I understand it, this bug is about adapting yast2-nfs-client to work with the new systemd units of nfs-utils, which are not present on SLE 12. It does not make sense for SP1 unless nfs-utils is upgraded there. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 http://bugzilla.suse.com/show_bug.cgi?id=911986#c5 Manfred Hollstein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manfred.h@gmx.net --- Comment #5 from Manfred Hollstein --- I just (two or three days ago) upgraded my TW installation from "openSUSE 20150612" to "openSUSE 20150712" and am now facing the situation that my formerly working NFSv4 server now just segfaults. Since I don't use the yast2-nfs module (FWIW, I doubt anyone really uses it for any productive use), I upgraded the relevant packages (nfs-client and nfs-kernel-server) to the current version 1.3.1-160.13 from Base:System repo and everything works as normal. May I suggest that refusing to accept a request for adopting a properly working module in a given environment (Factory/Tumbleweed) from dealing with a build-requires for an almost unusable yast-module for configuring an (otherwise broken) service is insane? Please, if yast2-nfs-client cannot be fixed, that it gets obsoleted somehow! The service is what's relevant, not a configuration module. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 http://bugzilla.suse.com/show_bug.cgi?id=911986#c7 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ancor@suse.com Flags| |needinfo?(nfbrown@suse.com) --- Comment #7 from Ancor Gonzalez Sosa --- Neil, correct me if I'm wrong but the nfs systemd service available in both Factory and SLE12-SP1 is, by no mean, a direct replacement to the nfs service available in SLE12 or 13.2. With the old init.d based service: 1) "status" checks for portmap, gssd and idmapd and also checks that all the shares in /etc/fstab are mounted 2) "start" mounts all the shares from /etc/fstab 3) "stop" umounts all the shares Thus, yast2 used "nfs stop && nfs start && nfs status" to reconfigure the system and check if the configuration was successful after clicking the finish button. But the new systemd based service is actually "just an alias" to nfs-client.target. Aliasing services to targets doesn't seem to be hassle-free. 1) "status" does not work as expected, "systemctl status nfs" always returns inactive no matter what "systemctl status nfs-client" returns. 2) "start" and "stop" doesn't have any effect on the mounted shares. I could adapt yast2-nfs-client to use the new way (whatever it is, guidance is appreciated) of (re)mounting the configured shares and checking the state, but I wonder if introducing such a big change in the semantic of the nfs service was actually intentional or is even appropiate for SLE12-SP1. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 http://bugzilla.suse.com/show_bug.cgi?id=911986#c8 --- Comment #8 from Neil Brown --- So many questions :-) I didn't check 'status'. If you add RemainAfterExit=yes to the [service] section of /usr/lib/systemd/system/nfs.service it seems to help. Can you check that? Mounts are certainly handled differently with systemd. Ideally we would be able to create dependencies between the nfs mount and the nfs.service. But I cannot see how to do that. Even more ideally, people wouldn't put nfs mounts in /etc/fstab, they would just use autofs... Presumably yast makes changes to /etc/fstab and then expects 'nfs stop; nfs start" to put those into effect. We can probably achieve that by adding ExecStartPost and ExecStop lines to nfs.service which run "mount -at nfs" and "umount -aft nfs". Can you try that or would you rather a provide a test package (would have to be next week). Is such a big change appropriate for SLE12-SP1?? Good question. proper systemd support seems to be a big-ticket item. Having half-and-half systemd and init.d would just cause on-going pain. So I think it is the right thing to do, and I appreciate you testing the result and letting me know the bits that I have missed. I'll get an updated package available for testing by early next week. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 http://bugzilla.suse.com/show_bug.cgi?id=911986#c10 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(nfbrown@suse.com) | --- Comment #10 from Ancor Gonzalez Sosa --- Neil, adding this three lines to nfs.service makes it behave much more similar to the old init.d version. Particularly it fixes all the problems I have experienced during my tests of yast2-nfs-client. RemainAfterExit=yes ExecStartPost=/usr/bin/mount -at nfs,nfs4 ExecStop=/usr/bin/umount -aft nfs,nfs4 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 http://bugzilla.suse.com/show_bug.cgi?id=911986#c14 --- Comment #14 from Ancor Gonzalez Sosa --- I have prepared the following openQA test to ensure the new nfs-utils fixes the problem with yast2-nfs-client (i.e. offers backwards compatibility with the init.d script) and to detect future breakage. https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/27cb6e7b90... https://github.com/os-autoinst/os-autoinst-needles-opensuse/commit/1566bfff6... Now the test fails. As soon as the new version of nfs-utils makes its way into Tumbleweed it should start working and I will open a pull request to integrate the test into openQA's regular workflow. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911986 http://bugzilla.suse.com/show_bug.cgi?id=911986#c16 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Ancor Gonzalez Sosa --- Looks like merging of the openQA test can take some time, but the fixed nfs-utils are already accepted into TW and SLE12-SP1. So closing. -- You are receiving this mail because: You are on the CC list for the bug.