Ondrej Valousek <[EMAIL PROTECTED]> writes: > Interesting thing: > I have 2 identical login01 and login02 machines (Rhel4, full updates). > login01 is running old kernel (2.6.9-42.ELsmp), login02 is running the > latest one (2.6.9-78.0.8.ELsmp). Both have autofs debug enabled and are > running the latest autofs (autofs-4.1.3-234). > Now: > 1) login01: > [EMAIL PROTECTED] ondrejv]# cat /var/log/debug.log* | grep "Dec 4 09:15:09" > Dec 4 09:15:09 login01 automount[3939]: handle_packet: type = 0 > Dec 4 09:15:09 login01 automount[3939]: handle_packet_missing: token > 3533, name .raw_data > Dec 4 09:15:09 login01 automount[3939]: attempting to mount entry > /proj/.raw_data > Dec 4 09:15:09 login01 automount[1649]: lookup(yp): looking up .raw_data > Dec 4 09:15:09 login01 automount[3939]: mt->key set to .raw_data > Dec 4 09:15:09 login01 kernel: automount[1649]: segfault at > 0000000000000000 rip 0000002a95916be0 rsp 0000007fbfffd5c8 error 4 > Dec 4 09:15:09 login01 automount[3939]: handle_child: got pid 1649, sig > 1 (11), stat 0 > Dec 4 09:15:09 login01 automount[3939]: sig_child: found pending iop > pid 1649: signalled 1 (sig 11), exit status 0 > Dec 4 09:15:09 login01 automount[3939]: send_fail: token=3533 > Dec 4 09:15:09 login01 automount[3939]: handle_packet: type = 0 > Dec 4 09:15:09 login01 automount[3939]: handle_packet_missing: token > 3534, name .raw_data > Dec 4 09:15:09 login01 automount[3939]: attempting to mount entry > /proj/.raw_data > Dec 4 09:15:09 login01 automount[1650]: lookup(yp): looking up .raw_data > Dec 4 09:15:09 login01 automount[3939]: mt->key set to .raw_data > Dec 4 09:15:09 login01 kernel: automount[1650]: segfault at > 0000000000000000 rip 0000002a95916be0 rsp 0000007fbfffd5c8 error 4
Can you enable core dumps and get us a stack trace of this? > Note that .raw_data map does not exist in the yp map so it should go > into the negative cache - which happens correctly on login02: > ov 28 23:27:43 login01 automount[4201]: attempting to mount entry > /proj/.raw_data > Nov 28 23:27:43 login01 automount[13394]: lookup(yp): looking up .raw_data > Nov 28 23:27:43 login01 automount[4201]: mt->key set to .raw_data > Nov 28 23:27:43 login01 automount[13394]: lookup(yp): key ".raw_data" > not found in map. > Nov 28 23:27:43 login01 automount[13394]: failed to mount /proj/.raw_data > Nov 28 23:27:43 login01 automount[13394]: umount_multi: > path=/proj/.raw_data incl=1 > Nov 28 23:27:43 login01 automount[4201]: handle_child: got pid 13394, > sig 0 (0), stat 3 > Nov 28 23:27:43 login01 automount[4201]: sig_child: found pending iop > pid 13394: signalled 0 (sig 0), exit status 3 > Nov 28 23:27:43 login01 automount[4201]: update_negative_cache: key: > .raw_data > Nov 28 23:27:43 login01 automount[4201]: Adding negative cache entry for > key .raw_data > Nov 28 23:27:43 login01 automount[4201]: Key .raw_data added to negative > cache > Nov 28 23:27:43 login01 automount[4201]: send_fail: token=15625 > > I thought all the negative caching is done in user space, but apparently > kernel has some influence here.... > Any explanation? The negative caching is done in userspace. I'm not sure I understand your question. Cheers, Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
