[comp.sys.alliant] problems porting amd to Concentrix 5.5.02

sjoerd@cwi.nl (Sjoerd Mullender) (08/03/90)

I am trying to port amd (Jan-Simon Pendry's automount daemon) to the
Alliant.  When we were running Concentrix 5.0.0, I had no problems doing
that, but since we are running 5.5.02, the automount daemon stopped
working.
By using adb I found that both amd and /etc/mount do a mount system call
with the exact same arguments.  The difference is that /etc/mount succeeds
in mounting the remote directory and amd fails.  Mount returns with an
errno of EDEADLK "Deadlock situation detected/avoided".  This error is
not documented in the manual.
Can anyone tell me why the kernel returns this errno?  Needless to say,
we don't have the source for the kernel.

Thanks in advance.
--
Sjoerd Mullender		Center for Mathematics and Computer Science
sjoerd@cwi.nl			Amsterdam, Netherlands

prl@ethz.UUCP (Peter Lamb) (08/06/90)

In article <1926@charon.cwi.nl>, sjoerd@cwi.nl (Sjoerd Mullender) writes:
> I am trying to port amd (Jan-Simon Pendry's automount daemon) to the
> Alliant.  When we were running Concentrix 5.0.0, I had no problems doing
> that, but since we are running 5.5.02, the automount daemon stopped
> working.

As a followup to Sjoerd, we have had exactly the same problem here.
Recompiling under 5.5.03 doesn't help either. Don't bother trying
to recompile under 5.5.02; the 5.5.02 patch scrunges /usr/include/netdb.h
and installs a flakey syslog.o in libc.a -- both fixed by 5.5.03.

A workaround may be to use the `program' mount type, and have that call
mount and umount as appropriate. This is also rumoured to be needed for
Ultrix/RISC. I haven't tried this yet, and I don't know if the problem
is the identical on Ultrix/RISC.


-- 
Peter Lamb
uucp:  uunet!mcsun!ethz!prl	eunet: prl@iis.ethz.ch	Tel:   +411 256 5241
Integrated Systems Laboratory
ETH-Zentrum, 8092 Zurich

werme@Alliant.COM (Ric Werme) (08/07/90)

In article <1926@charon.cwi.nl> sjoerd@cwi.nl (Sjoerd Mullender) writes:
>By using adb I found that both amd and /etc/mount do a mount system call
>with the exact same arguments.  The difference is that /etc/mount succeeds
>in mounting the remote directory and amd fails.  Mount returns with an
>errno of EDEADLK "Deadlock situation detected/avoided".  This error is
>not documented in the manual.

>Can anyone tell me why the kernel returns this errno?  Needless to say,
>we don't have the source for the kernel.

I thought I'd poke around a bit in a spare moment.  EDEADLK is new to
4.3 BSD and involves interlocking file system accesses.  There's a
global lock that the mount and umount code takes.  Off hand the only
way I see for this to occur is if another mount is going on in parallel.
I think NFS mounts hold this until the remote system replies, which can
be quite a while.

Does amd fork multiple copies of itself to try to run faster?  If so,
see if you easily defeat that.

I'm not sure if other 4.3 BSD sites would have the same problem, because
we had to change just about everything related to locking.
-- 

| A pride of lions              | Eric J Werme                |
| A gaggle of geese             | uucp: decvax!linus!alliant  |
| An odd lot of programmers     | Phone: 603-673-3993         |

sjoerd@cwi.nl (Sjoerd Mullender) (08/09/90)

sjoerd@cwi.nl (Sjoerd Mullender) (that's me) writes:

>I am trying to port amd (Jan-Simon Pendry's automount daemon) to the
>Alliant.  When we were running Concentrix 5.0.0, I had no problems doing
>that, but since we are running 5.5.02, the automount daemon stopped
>working.
>By using adb I found that both amd and /etc/mount do a mount system call
>with the exact same arguments.  The difference is that /etc/mount succeeds
>in mounting the remote directory and amd fails.  Mount returns with an
>errno of EDEADLK "Deadlock situation detected/avoided".  This error is
>not documented in the manual.

I have seen two followups on this message.  In one, Peter Lamb suggested
the `program' mount type.  I have tried that, but I got the same error.
Ric Werme poked around a bit and found that EDEADLK involves interlocking
file system accesses.
What I think is happeing is the following.  Amd mounts a directory, using
the NFS mount options and acts as the nfs server for that directory.  In my
case, the directory is called /hosts.  Now when I access a directory inside
/hosts, the kernel sends a message to the nfs server of /hosts (that is: amd).
Amd then tries to mount the file system you want to access.  After the
mount succeeds, amd sends a message back to the kernel.  My theory is that
while the kernel is waiting for the reply of the nfs server (that is, amd)
you cannot mount any NFS file systems.  If this is indeed the case, it is
impossible to get an automounter to work on Concentrix 5.5.02.

Any thoughts on this from anyone?  Alliant?
--
Sjoerd Mullender		Center for Mathematics and Computer Science
sjoerd@cwi.nl			Amsterdam, Netherlands