Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
In Fedora 20 and the latest F19 kernel, amd will not start: TenMen ~ # amq amq: localhost: RPC: Program not registered TenMen ~ # amd Mar 10 12:43:04 TenMen amd[11484]/info: using configuration file /etc/amd.conf TenMen ~ # amq / root "root" /net error . //nil// TenMen ~ # journalctl -xn ... Mar 10 12:43:04 TenMen amd[11485]: Trying mount of /etc/amd.net on /net fstype toplvl mount_type non-autofs Mar 10 12:43:04 TenMen amd[11485]: creating mountpoint directory '/net' Mar 10 12:43:04 TenMen amd[11486]: '/net': mount: Protocol not supported Mar 10 12:43:05 TenMen amd[11486]: '/net': mount: Protocol not supported Mar 10 12:43:05 TenMen amd[11486]: amfs_toplvl_mount: amfs_mount failed: Protocol not supported Mar 10 12:43:05 TenMen amd[11485]: /net: mount (amfs_cont): Protocol not supported
Hi Norman, LOL, why am I not surprised to see this ... Let me install F20 in a VM and check what the NFSv2 situation is. Also, I'll ask about it tonight when the US folks come online. Ian
OK, that didn't take long. I see Steve Dixon has disabled NFSv2 in the kernel configuration so the module it isn't compiled any more. I'll ask him if he's willing to enable it again but I suspect he will not want to. You could re-compile the kernel with a configuration that has NFSv2 enabled from the srpm and that would resolve the problem. As far as updating am-utils to use NFSv3 is concerned that's really is a task for am-utils upstream. We could consider patching autofs to understand amd maps but the testing hasn't progressed quite far enough yet. There's also the question of whether the new amd parser in autofs will cover your needs. What am-utils features do you use? Would you be willing to participate in testing this if the functionality you need is covered? Ian
I've had a look at the am-utils source and while it appears straight forward to change am-utils to use NFSv3 I'm not sure that it is. There's a the different NFS file handle size, a couple of service functions removed, some added and some changed. Steve, when using amd mount_type nfs (not autofs) am-utils registers an NFSv2 UDP server service and uses the NFS client to mount its top level automounter directories. So not compiling NFSv2 support in the kernel client stops it from working.
Created attachment 876727 [details] Patch - dont background autofs umount
Created attachment 876728 [details] Patch - check fh on umount succeeded
Created attachment 876729 [details] Patch - handle ENOENT umount return for autofs mounts
Created attachment 876730 [details] Patch - fix get_nfs_version() message
Created attachment 876731 [details] Patch - fix debug log deadlock
Created attachment 876732 [details] Patch - linux umount wait on ebusy
Created attachment 876733 [details] Patch - make sure to remove nodes in the proper order when going down
Created attachment 876735 [details] Patch - fix handle failed umount on exit
Created attachment 876736 [details] Patch - fix autofs proto version define
am-utils-6.1.5-30.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/am-utils-6.1.5-30.fc20
This is about as far as I can go with this problem. The above revision appears to work with mount_type autofs and I believe I've fixed the shutdown hang I was seeing. Problems that still remain are: 1) mount_type nfs doesn't work unless you rebuild the kernel from a source rpm with CONFIG_NFS_V2=m or CONFIG_NFS_V2=y. 2) If there are mounts still mounted from a previous instance of amd they cannot be re-used and those mounts will no longer function until amd is shutdown, the mounts manually umounted and amd started again. Not a new problem by any means. 3) If there are mounts actually in use at shutdown (ie. a process has an automunted directory as its working directory or at least one file is open within an automounted directory) the daemon will refuse to exit. The above issues are really something that the upstream maintainers need to fix and that's not me, I have enough to do already with what I maintain. If you need the functionality of 2) and 3) above then you need to consider using autofs with amd map format support. I hope to release the first beta in the next several days. I will post the location of the tar and instructions on how to build a binary rpm for testing to this bug when it's available. Ian
Awesome work Ian! I'll get on to testing what I can. Is is too much to ask for a F19 build as well? Sorry for the delay in responding. I posted the bug at a bad time :-( My use of am-utils is quite modest with less than 100 lines of map files. If autofs could read amd map files and do the same functionality that I use, well I should just convert to autofs instead. I don't really see the point of autofs actually being able to use amd map files. A map file converter/helper is really all I would use. Sounds like NFS2 in the kernel is not what is going to happen. Sounds sensible but it will mean upstream am-utils will need do something if they want am-utils to live in the linux world. My use of am-utils is as follows: - the /net map. This is standalone and does not interact with other maps. - A /disks map where all the disk areas in our network are named and given a mount point. So typically the amd map entry would look like: hosta type:=auto;fs:=${map};pref:=${key}/ hosta/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME hosta/projects host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ host==${key/};type:=ufs;dev:=/dev/BIGDISK/PROJECTS hostb type:=auto;fs:=${map};pref:=${key}/ hostb/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME The second part of the map where host==${key/} is not used. That is handled by fstab on each system. So with that, any disk area can be named on any host, for example in the above maps: /.a/hosta/disks/hosta/home/ /.a/hosta/disks/hosta/projects/ /.a/hostb/disks/hostb/home/ - Other maps that use the symbolic links to point to areas in the /disks maps. I have 2 of these one for /home dirs and one for /projects. Example projects: /defaults type:=link mirrors fs:=/disks/hosta/projects/mirrors linux fs:=/disks/hosta/projects/mirrors/linux fedora fs:=/disks/hosta/projects/mirrors/linux/fedora So on any system I can "ls /projects/fedora/" for example. - Finally I distribute the 4 master map files via NIS. So each amd.conf on each host has amd mount points for /net /disks /home /projects that look similar to: [/disks] map_name = amd.disks map_type = nis Hope that answers all your questions :-) I wonder how much am-utils is really used in Fedora and even EL. A build has not been available for EL for some time. I use an old am-utils-6.1.5-17.fc14.x86_64
In the above example, I showed where all the disks are mounted. Of course on any system, the location of the disks as used by the other maps would be: /disks/hosta/home/ /disks/hosta/projects/ /disks/hostb/home/
(In reply to Norman Gaywood from comment #16) > Awesome work Ian! I'll get on to testing what I can. Is is too much to ask > for a F19 build as well? Sure, but lets work through the F20 changes first. > > Sorry for the delay in responding. I posted the bug at a bad time :-( I figured that, ;) > > My use of am-utils is quite modest with less than 100 lines of map files. If > autofs could read amd map files and do the same functionality that I use, > well I should just convert to autofs instead. I don't really see the point > of autofs actually being able to use amd map files. A map file > converter/helper is really all I would use. I considered that but after manually converting a setup that used a range of amd features I realized that converting an amd map to a Sun format is far from straight forward. Handling the key lookup and the sublink option in particular is really problematic. And then there's the selectors which, in most cases, don't have a parallel in autofs. Then there's the issue of people that have provisioning systems that update amd maps and would expect to be able to run the converter on a regular basis and have it work without the need for manual tweaking. And there's also the plethora of configuration options that can affect the lookup and mount process .... All in all I concluded that adding a parser module to autofs would more reliable and a much lower ongoing maintenance option. In any case adding a parser module to autofs is, in many ways, just a sophisticated map converter. > > Sounds like NFS2 in the kernel is not what is going to happen. Sounds > sensible but it will mean upstream am-utils will need do something if they > want am-utils to live in the linux world. Probably not. > > My use of am-utils is as follows: > > - the /net map. This is standalone and does not interact with other maps. > > - A /disks map where all the disk areas in our network are named and given a > mount point. So typically the amd map entry would look like: > > hosta type:=auto;fs:=${map};pref:=${key}/ > hosta/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME > hosta/projects host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > host==${key/};type:=ufs;dev:=/dev/BIGDISK/PROJECTS > hostb type:=auto;fs:=${map};pref:=${key}/ > hostb/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME > > The second part of the map where host==${key/} is not used. That is handled > by fstab on each system. So with that, any disk area can be named on any > host, for example in the above maps: > > /.a/hosta/disks/hosta/home/ > /.a/hosta/disks/hosta/projects/ > /.a/hostb/disks/hostb/home/ So using mount_type nfs, when host==${key/} you would end up with a symlink from /disks/hosta/home -> /.a/hosta/disks/hosta/home and when host!=${key/} /.a/hosta/disks/hosta/home would end up as an NFS mount at the target of the symlink. I think that's how it works. And it will work a little differently when using mount_type autofs. I remember working on something like this during development. I'll create a test map and see what happens with the autofs parser. > > - Other maps that use the symbolic links to point to areas in the /disks > maps. I have 2 of these one for /home dirs and one for /projects. Example > projects: > > /defaults type:=link > mirrors fs:=/disks/hosta/projects/mirrors > linux fs:=/disks/hosta/projects/mirrors/linux > fedora fs:=/disks/hosta/projects/mirrors/linux/fedora > > So on any system I can "ls /projects/fedora/" for example. I'll test this one too but it looks like they are just plain old symlinks. I recommend a kernel update so that symlinks expire properly (although it should still work ok without it) and then using "autofs_use_lofs = no" in the autofs implementation can reduce resource usage somewhat. I found that the best choice during development. > > - Finally I distribute the 4 master map files via NIS. So each amd.conf on > each host has amd mount points for /net /disks /home /projects that look > similar to: > > [/disks] > map_name = amd.disks > map_type = nis In the autofs implementation map_name is ignored because the autofs master map is used for all map entries and it requires a map name. Using nis is fine and the README.amd-maps talks about what to add to the autofs configuration. Basically, cut and past amd.conf and change "[ global ]" to "[ amd ]" is all. > > Hope that answers all your questions :-) Indeed, time to see if I've done my job well or not! > > I wonder how much am-utils is really used in Fedora and even EL. A build has > not been available for EL for some time. I use an old > am-utils-6.1.5-17.fc14.x86_64 Yeah, that's a good question and the answer is probably not many, but for largish sites that do, this can be a real problem. Ian
(In reply to Norman Gaywood from comment #16) > > My use of am-utils is as follows: > > - the /net map. This is standalone and does not interact with other maps. > > - A /disks map where all the disk areas in our network are named and given a > mount point. So typically the amd map entry would look like: > > hosta type:=auto;fs:=${map};pref:=${key}/ > hosta/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME > hosta/projects host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > host==${key/};type:=ufs;dev:=/dev/BIGDISK/PROJECTS > hostb type:=auto;fs:=${map};pref:=${key}/ > hostb/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME I see a problem with this already. I've actually missed ufs (one of the few types not catered for) altogether and even if I had I fail the map entry parse when I see an unsupported type. I already have this error handling case on my TODO list but haven't got to it yet, ie. don't fail on the parse, handle it later at mount time, if it comes to that. I'll keep you updated. Ian
Package am-utils-6.1.5-30.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing am-utils-6.1.5-30.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4162/am-utils-6.1.5-30.fc20 then log in and leave karma (feedback).
(In reply to Ian Kent from comment #19) > (In reply to Norman Gaywood from comment #16) > > > > My use of am-utils is as follows: > > > > - the /net map. This is standalone and does not interact with other maps. > > > > - A /disks map where all the disk areas in our network are named and given a > > mount point. So typically the amd map entry would look like: > > > > hosta type:=auto;fs:=${map};pref:=${key}/ > > hosta/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > > host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME > > hosta/projects host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > > host==${key/};type:=ufs;dev:=/dev/BIGDISK/PROJECTS > > hostb type:=auto;fs:=${map};pref:=${key}/ > > hostb/home host!=${key/};type:=nfs;rhost:=${key/};rfs:=/disks/${key} \ > > host==${key/};type:=ufs;dev:=/dev/BIGDISK/HOME > > I see a problem with this already. > > I've actually missed ufs (one of the few types not catered for) > altogether and even if I had I fail the map entry parse when I > see an unsupported type. > > I already have this error handling case on my TODO list but > haven't got to it yet, ie. don't fail on the parse, handle it > later at mount time, if it comes to that. > > I'll keep you updated. I see there's another problem with amd when using mount_type autofs. You appear to rely on amd using mounts in the lookaside directory, something like /.a/hosta/disks/hosta/home I think. But amd will mount these in place when using mount_type autofs. What's possibly worse is that if multiple map entries reference the same mount I think it will fail to mount (in place) since it's already mounted elsewhere. Just a thought ...
(In reply to Ian Kent from comment #21) > > I see there's another problem with amd when using mount_type autofs. > > You appear to rely on amd using mounts in the lookaside directory, > something like /.a/hosta/disks/hosta/home I think. But amd will > mount these in place when using mount_type autofs. What's possibly > worse is that if multiple map entries reference the same mount I > think it will fail to mount (in place) since it's already mounted > elsewhere. > > Just a thought ... Umm .. that assumes that the problem with linux mount in amd is fixed so it can actually mount ext* (and maybe xfs) file systems, what it can't now. Ian
am-utils-6.1.5-30.fc20.x86_64 is working for me in F20 with: mount_type = autofs in the global section of /etc/amd.conf There are some caveats that I think you have mentioned in your comments above. Now that mounts are done in place, some symbolic links break in the underlying mounted filesystems because of some of my assumptions on where files were located. No big deal for me. The case of a mount failing because it has already been done elsewhere may exist in my maps, but I've not found it yet (if I understand things correctly). Might be a problem for others, but I think these things can be worked around. As I mentioned above, I don't use the type:=ufs part of the map anymore. I rely on fstab on each system instead and amd inherits the mounts. This is enough for me to get by until I convert to the linux autofs. These days I only use linux (Fedora and Centos) so the need for am-utils, as much as I like it, has passed. Sorry for the delay again, most of Fedora is F19, took awhile to get a F20 VM to test with.
(In reply to Norman Gaywood from comment #23) > am-utils-6.1.5-30.fc20.x86_64 is working for me in F20 with: > > mount_type = autofs > > in the global section of /etc/amd.conf > > There are some caveats that I think you have mentioned in your comments > above. Now that mounts are done in place, some symbolic links break in the > underlying mounted filesystems because of some of my assumptions on where > files were located. No big deal for me. Yep, thought that would be the case. > > The case of a mount failing because it has already been done elsewhere may > exist in my maps, but I've not found it yet (if I understand things > correctly). Might be a problem for others, but I think these things can be > worked around. Yeah, I saw this in my simple autofs amd mount testing but it doesn't always happen so I'm not sure of the specific conditions that result in it happening. No big deal I guess. > > As I mentioned above, I don't use the type:=ufs part of the map anymore. I > rely on fstab on each system instead and amd inherits the mounts. Right but I was referring to the way in which amd mount type nfs will use external mounts and if they are mounted already they will be used, but mount_type autofs doesn't get that and will mount them in place, which I think isn't what you need. Anyway there's nothing we can do about it since that's a fundamental amd change, too much to be concerned with here. Ian
I've also installed (yum localinstall) am-utils-6.1.5-30.fc20.x86_64 on an F19 test system and it seems to be working the same way as on F20. Nice work Ian. You got me out of trouble and allowed me to stumble a bit further with am-utils. Writing is on the wall though. I need to put in the work to convert to linux autofs.
(In reply to Norman Gaywood from comment #25) > I've also installed (yum localinstall) am-utils-6.1.5-30.fc20.x86_64 on an > F19 test system and it seems to be working the same way as on F20. > > Nice work Ian. You got me out of trouble and allowed me to stumble a bit > further with am-utils. > > Writing is on the wall though. I need to put in the work to convert to linux > autofs. Your setup should work as is in autofs with the amd format map parser. The only change that should be needed is to add your amd.conf to the bottom of (the new) autofs.conf and change "[ global ]" to "[ amd ]". Although you'll probably want to comment out some configuration directives to stop autofs telling you they aren't used. I'm always a bit nervous releasing a large change like this but I'll likely cave in and release a beta by the end of the coming weekend.... Ian
am-utils-6.1.5-30.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/am-utils-6.1.5-30.fc19
am-utils-6.1.5-30.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
am-utils-6.1.5-30.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.