stopping amd causes a freeze

[Konstantin Belousov]

On Sat, Jul 27, 2013 at 10:33:18AM +0200, Dominic Fandrey wrote:
> On 26/07/2013 19:10, Dominic Fandrey wrote:
> > On 25/07/2013 12:00, Konstantin Belousov wrote:
> >> On Thu, Jul 25, 2013 at 09:56:59AM +0200, Dominic Fandrey wrote:
> >>> On 22/07/2013 12:07, Konstantin Belousov wrote:
> >>>> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote:
> >>>>> ...
> >>>>>
> >>>>> I run amd through sysutils/automounter, which is a scripting solution
> >>>>> that generates an amd.map file based on encountered devices and devd
> >>>>> events. The SIGHUP it sends to amd to tell it the map file was updated
> >>>>> does not cause problems, only a -SIGKILL- SIGTERM may cause the freeze.
> >>>>>
> >>>>> Nothing was mounted (by amd) during the last freeze.
> >>>>>
> >>>>> ...
> >>>>
> >>>> Are you sure that the machine did not paniced ?  Do you have serial console ?
> >>>>
> >>>> The amd(8) locks itself into memory, most likely due to the fear of
> >>>> deadlock. There are some known issues with user wirings in stable/9.
> >>>> If the problem you see is indeed due to wiring, you might try to apply
> >>>> r253187-r253191.
> >>>
> >>> I tried that. Applying the diff was straightforward enough. But the
> >>> resulting kernel paniced as soon as it tried to mount the root fs.
> >> You did provided a useful info to diagnose the issue.
> >>
> >> Patch should keep KBI compatible, but, just in case, if you have any
> >> third-party module, rebuild it.
> >>
> >>>
> >>> So I'll wait for the MFC from someone who knows what he/she is doing.
> >>
> >> Patch below booted for me, and I run some sanity check tests for the
> >> mlockall(2), which also did not resulted in misbehaviour.
> >>
> > 
> > Your patch applied cleanly and the system booted with the resulting
> > kernel.
> > 
> > Amd exhibits several very strange behaviours. ...
> 
> I can verify the whole thing with a clean world and kernel.
> 
> This time I'll concentrate on the first instance of amd:
> 
> # tail -n3 /var/log/messages
> Jul 27 10:08:56 mobileKamikaze kernel: newnfs server pid5868 at mobileKamikaze:/var/run/automounter.amd.mnt: not responding
> Jul 27 10:09:41 mobileKamikaze kernel: newnfs server pid5868 at mobileKamikaze:/var/run/automounter.amd.mnt: not responding
> Jul 27 10:11:41 mobileKamikaze last message repeated 3 times
> 
> The process, it turns out, simply doesn't exist. There is another
> process, though:
> # ps auxww | grep -F sbin/amd
> root       5869   0.0  0.1  12036   8020 ??  S    10:08am   0:00.01 /usr/sbin/amd -r -p -a /var/run/automounter.amd -c 4 -w 2 /var/run/automounter.amd.mnt /var/run/automounter.amd.map
> 
> # cat /var/run/automounter.amd.pid
> 5868
> 
> Here is what I think happens, amd forks a subprocess and the main
> process, silently dies after it wrote its pidfile.
Nothing dies silently.  Either process was killed by signal, or it
exited with the explicit call to exit(2).  In the first case, default
kernel settings of kern.logsigexit should make a record in the syslog.
The machdep.uprintf_signal might be also useful, but not for daemons.

If the process called exit(2), ktrace would show it.

> 
> For completeness:
> # mount
> /dev/ufs/5root on / (ufs, local, noatime, soft-updates)
> devfs on /dev (devfs, local, multilabel)
> /dev/ufs/5stor on /pool/5stor (ufs, local, noatime, soft-updates)
> /pool/5stor/usr on /usr (nullfs, local, noatime)
> /pool/5stor/var on /var (nullfs, local, noatime)
> /usr/home/root on /root (nullfs, local, noatime)
> tmpfs on /var/log (tmpfs, local)
> tmpfs on /var/run (tmpfs, local)
> tmpfs on /tmp (tmpfs, local)
> 
> Everything else seems to work. I'll revert your patch for now and
> wait for the MFC.

I was unable to get useful information from any of your posts.
My current plan is to merge the revisions after the 9.2 freeze is over.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130728/144c0193/attachment.sig>