I've lately noticed a very annoying behavior using recently-updated NetBSD-7 and 'firefox-43.0nb1' from pkgsrc-2015Q4.
Client machine using 'amd' to mount home directory from file server. Run 'firefox' on client machine. Perform 'cvs update' on file server with trees on same filesystem served for home directory above. 'amd' process managing the home directory mount on the client becomes stuck in 'tstile'. If logged in via 'ssh', parent shell also stuck in 'tstile'. 'sshd' child process may become stuck in 'tstile' or may sit in 'select'. 'firefox' may become stuck in 'tstile', or may begin alternating between 'RUN' and 'parked'. Any access to any 'amd'-managed automount filesystem hangs, including 'df' and 'mount'. Eventually, even access to "/" hangs. Processes become stuck in 'tstile' and cannot be killed. Client machine cannot be rebooted. Hard reset or forced power-cycle is the only way to regain control. There is typically local filesystem damage to clean up afterward. The trigger seems to be the combination of 'firefox' on the client and performing 'cvs update' on the server. 'amd'-using clients not running 'firefox' survive, although it takes a while for the next access to an 'amd'-managed mountpoint to complete. It used to work just fine. I should note that the recent nfs-related pull-ups to netbsd-7 are on all clients but the server has not yet been updated. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
