Following up on the "request-key" issue, although it's sort of hijacking Daniel's thread: could be related in the sense that I wonder if using the 6.3 kernel in 6.2 isn't the source of many similar problems. In the new kernel changelog I see:
* Wed Feb 29 2012 Aristeu Rozanski <[email protected]> [2.6.32-245.el6] - [build] update RHEL_MINOR to '3' (Aristeu Rozanski) - [fs] keyring: allow special keyrings to be cleared (Steve Dickson) [772495] - [fs] NFS: Update idmapper documentation (Steve Dickson) [772495] - [fs] NFS: Keep idmapper include files in one place (Steve Dickson) [772495] - [fs] NFS: Fall back on old idmapper if request_key() fails (Steve Dickson) [772495] which explains why there are messages in /var/log/secure but no actual failures like the older bug report mentions. Unfortunately, this bugzilla is restricted so no more info can be gleaned. Updating a test machine to the 6.3 RC, the request-key errors go away. I interpret this as the new kernel seeing the the idmapper version in 6.2 (nfs-utils-1.2.3-15) as "old" but being happy with the version in 6.3 (nfs-utils-1.2.3-26). Just the sort of backport bug you'd expect by taking a 6.3 kernel and releasing it as a 6.2 update. The nfs-utils changelog does list a lot of idmapper changes on the same date: * Wed Feb 29 2012 Steve Dickson <[email protected]> 1.2.3-16 - Enable the keyring based idmapping (bz 772496) - Correct nfs(5) man page on how TCP retries are done (bz 737990) - Fixed sigio problem in rpc.idmapd (bz 751089) - Only link in libtirpc to binaries that need it (bz 772050) - Increase the stdio file buffer size for procfs files (bz 736741) - Fixed gssd from picking the wrong creds (bz 738774) - Mounts fail with using -o bg,vers= options (bz 740472) So: looks like updating the nfs-utils should be a requirement of updating the kernel: if that doesn't break other stuff, which I'm not in a good position to test. Question for Pat: given that I can't read the bug report in question, do I file a new one? Or is this a SL problem not a TUV issue? (not sure of the provenance of the 6.3 kernel appearing in the 6.2 updates directory). Alec Alec T. Habig writes: > Daniel Kontsek writes: > > > > all of my SL 6.2 machines proposed today a kernel update to > > 2.6.32-279.1.1.el6, which would probably make them unreachable after > > reboot. This kernel is also included in the 6.3 release. > > Another problem which came with this kernel update is thankfully > annoying rather than fatal. /var/log/secure is filling up with things > like: > > request-key: Cannot find command to construct key 100834592 > > (where the int after "key" changes). > > Looks similar to: > > https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=794780 > > which came into the fedora kernel when it was the version we're using in > SL6 now, but which has been fixed in Fedora for a while. > > Anyway: if anybody else has noticed this, let me know as I try to get a > proper bugzilla cooked up, so I can include your information too. > > Alec > -- Alec Habig, University of Minnesota Duluth Physics Dept. [email protected] http://neutrino.d.umn.edu/~habig/
