I have spoken with radhermit about this, but I'm also opening this bug so we can track it here. When fixing bug #427996, I made a change that should not have been made. netmount was skipping mounting and unmounting nfs file systems. This was fixed in bug #508574. The complete fix is included in OpenRC-0.13.4. This means that the following should happen in nfs-utils. 1. /etc/init.d/nfsmount is no longer necessary with this version of OpenRC. 2. All of the init scripts in nfs-utils should have "before netmount" added to their depend function. Radhermit has given me permission to make this happen, but I don't want to touch the init scripts directly without approval since there is no way for me to test, (I don't use nfs), so I'll attach a patch here for review.
the current nfs-utils init script isn't very current, however, it has some great things for calculating deps of the init script automatically based on what is in fstab. this should be ported to netmount so it can start the needed services automatically.
(In reply to Rick Farina (Zero_Chaos) from comment #1) > the current nfs-utils init script isn't very current, however, it has some > great things for calculating deps of the init script automatically based on > what is in fstab. this should be ported to netmount so it can start the > needed services automatically. Or we could make nfsmount not mount anything and just run before netmount. I'll definitely talk to the herd members before I do anything with this.
My proposal for this is to modify nfsmount.initd so that it doesn't really mount anything; it would just make sure the nfs client services are started. I also propose renaming the script to nfsclient.initd, because nfsclient is a better description of what it does, and because renaming it means we don't interfeer with older versions of nfs-utils in the tree when we do the revbump. I don't know if any services have a dependency on nfsmount, so I will make nfsclient provide it just to be sure. I will not post nfsclient.confd because it is identical to nfsmount.confd, but I will post nfsclient.initd and the patch which shows the differences between nfs-utils-1.3.0-r1 and nfs-utils-1.3.0-r2. Please test and let me know how this works.
Created attachment 389442 [details, diff] nfs-utils-1.3.0.patch This is the differences between nfs-utils-1.3.0-r1 and nfs-utils-1.3.0-r2.
Created attachment 389444 [details] nfsclient.initd This is the nfsclient service script. As I said above, I will not attach nfsclient.confd, because it is identical to nfsmount.confd.
So instead of needing just nfsmount script to mount my nfs shares, now I need netmount AND nfsclient in default runlevel? How does this help me at all? Why not just build this into the netmount script? My objection to this is the same as always, you are not making things easier, you are making them harder.
We had a discussion about this on IRC, but I am going to respond here so that the others on the team will see my response. (In reply to Rick Farina (Zero_Chaos) from comment #6) > So instead of needing just nfsmount script to mount my nfs shares, now I > need netmount AND nfsclient in default runlevel? How does this help me at > all? Why not just build this into the netmount script? Netmount should not start the nfs client services. This is the way all of the network file systems we have work as far as I know. netmount tries to mount them, but is not responsible for starting their services. The problem with netmount running the nfs client services is that I have no way to know how other distros configure them, so there is no way for me to set up the dependencies. This bug offers the way for Gentoo to be sure the nfs client services are started before netmount runs and tries to mount the nfs file systems.
(In reply to William Hubbs from comment #7) > We had a discussion about this on IRC, but I am going to respond here so > that the others on the team will see my response. > > (In reply to Rick Farina (Zero_Chaos) from comment #6) > > So instead of needing just nfsmount script to mount my nfs shares, now I > > need netmount AND nfsclient in default runlevel? How does this help me at > > all? Why not just build this into the netmount script? > > Netmount should not start the nfs client services. This is the way all of > the network file systems we have work as far as I know. netmount tries to > mount them, but is not responsible for starting their services. > > The problem with netmount running the nfs client services is that I have no > way to know how other distros configure them, so there is no way for me to > set up the dependencies. > > This bug offers the way for Gentoo to be sure the nfs client services are > started before netmount runs and tries to mount the nfs file systems. Just to be clear, my issue is that we are going from a script called "nfsmount" which actually mounts my nfs shares, to needing TWO scripts in the default runlevel just to do what one is doing now. The reasoning for this? So we don't mess up other distros. I don't want to sound insensitive, I'm happy other distros work with openrc. That said, this is not a good idea. We should be fixing this so that one init script can handle things, it shouldn't be hard to add an "if [ $distro = gentoo ]" or similar and get things right. If other distros need to have multiple scripts to make nfs work that is fine, but why cripple function for gentoo with no gain? Let's make this work... please?
(In reply to Rick Farina (Zero_Chaos) from comment #8) > Just to be clear, my issue is that we are going from a script called > "nfsmount" which actually mounts my nfs shares, to needing TWO scripts in > the default runlevel just to do what one is doing now. > > The reasoning for this? So we don't mess up other distros. I'm all for consistency, meaning that we should work towards having all netfs related init scripts handling their own mounting or not. In this case it seems we're moving towards one script for mounting with all the others handling the various required services for the related network filesystems. There are upsides/downsides to either way, I assume this method was chosen to try to separate as much specific case by case netfs stuff out of netmount. > I don't want to sound insensitive, I'm happy other distros work with openrc. > That said, this is not a good idea. We should be fixing this so that one > init script can handle things, it shouldn't be hard to add an "if [ $distro > = gentoo ]" or similar and get things right. If other distros need to have > multiple scripts to make nfs work that is fine, but why cripple function for > gentoo with no gain? Let's make this work... please? I don't think "cripple" is a good word to use here when we're just talking about splitting up init scripts to achieve more consistency. I think we'd all be happy to hear other proposed ideas or look at other patches, but I don't think turning netmount into a singular script handling all cases is the best solution.
Created attachment 391230 [details, diff] nfsclient.initd.patch This is a patch that shows the differences between nfsmount and my proposed nfsclient script, also the ebuild patch above still applies. I also worked out a way to fix bug #529568 which is included in this patch. The other advantage of this patch is it eliminates the awk call by using OpenRC's fstabinfo to get the same information.
Fixed in 1.3.1.
Did anyone test nfsclient script? The part that detects rpc.gssd doesn't work - you can't modify a variable inside a pipe cause I guess that code runs in a subshell or smth.
(In reply to parafin from comment #12) > Did anyone test nfsclient script? The part that detects rpc.gssd doesn't > work - you can't modify a variable inside a pipe cause I guess that code > runs in a subshell or smth. Should be fixed in 1.3.1-r1.
