Date: Tue, 23 Jul 2013 11:52:58 -0700 From: Artem Belevich <art@freebsd.org> To: Dominic Fandrey <kamikaze@bsdforen.de> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: stopping amd causes a freeze Message-ID: <CAFqOu6jEXKHcdZjoU3kY5qPbhdGpFrbLDXyhAsRZ2bPRJNtaEA@mail.gmail.com> In-Reply-To: <51EEC0A4.7010508@bsdforen.de> References: <51ED0060.2050502@bsdforen.de> <CAFqOu6jkH0yWnWddGwZktLmBzGGHpurkEaeiqN11ArHjmW8q_w@mail.gmail.com> <51EEC0A4.7010508@bsdforen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 23, 2013 at 10:43 AM, Dominic Fandrey <kamikaze@bsdforen.de>wrote: > > Don't use KILL or make sure that nobody tries to use amd mountpoints > until > > new instance starts. Manually unmounting them before killing amd may > help. > > Why not let amd do it itself with "/etc/rc.d/amd stop" ? > > That was a typo, I'm using SIGTERM. Sorry about that. > > On SIGTERM amd will attempt to unmount its mountpoints. If someone is using them, unmount may not succeed. I've no clue what amd does in such case. The point is that you should treat amd restart as reboot of an NFS server. amd map reload does not really require amd restart. In some cases you may have to manually unmount some automounted filesystem if underlying map had changed, but that's the only case I can think of off the top of my head. In most of the cases "amq -f" worked well enough for me. By the way, are you absolutely sure that your script that restarts amd is guaranteed not to touch anything mounted with amd? Otherwise you're risking a deadlock. For example, if PATH contains amd-mounted directory then when it's time to execute next command your script may attempt to touch such path and may hang waiting for amd to respond which will never happen because the script can't start it. Now, back to debugging your problem. One way to check what's going on would be to figure out where do the processes get stuck. Start with "ps -axl" and see STAT field. CHances are that stuck processes will be in uninterruptible sleep state 'D'. Check MWCHAN field for those. Hitting '^T' which normally sends SIGINFO should also produce a message that includes process' wait channel and is convenient to use when you have console where you've started the app that is hung. Dig further into the sleeping process with "procstat -kk PID" -- it will give you in-kernel stack trace for process' threads which should whos what's going on. You may want to do it from a root login with local host directory and minimalistic PATH so it does not touch any amd mount points. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqOu6jEXKHcdZjoU3kY5qPbhdGpFrbLDXyhAsRZ2bPRJNtaEA>