Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B Funk)
Newsgroups: comp.sys.apollo
Subject: Re: Here's a new one ... (crp problem)
Message-ID: <9002161039.AA00187@icaen.uiowa.edu>
Date: 16 Feb 90 10:07:21 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 35

In posting <9002142151.AA18092@richter.mit.edu> krowitz@richter.mit.edu (David Krowitz) says:

> I've just found a new oddity with my mixed SR9.7/SR10.2 network ...
> The `node_data/tmp directories of the SR9.7 nodes are filling up
> with files of the form "crp00", "crp01", "crp02", etc. Apparently
> a new file is created each time I crp onto a SR9.7 node from an
> SR10.2 node. When "crp99" is reached, I can no longer crp onto
> the SR9.7 node from an SR10 node, although I can still crp onto it
> from another SR9.7 node. The error manifests itself on the SR10
> nodes with the message "no more resources". 
> 
> The quick fix is to simply delete the offending "crpxx" files from
> the SR9.7 nodes with the command "dlf -f -nq -du //?*/sys/node_data?*/tmp/crp??",
> but can anyone shed any light on why this is happening?

    Pre sr10, the "crp" mailboxes were created and reused in
the `node_data directory. At sr10 they were moved into "/dev"
(actually `node_data/dev) to be JLRU. (Unix doesn't understand
"tty" devices that aren't in /dev.) To create & reuse them there,
"/dev" must be world writeable. As you can run a sr9.7 system with
out having "/dev" world writeable, yours might not be if you have
very tight ACLs. (We ran it that way.) So when a sr10 crp encounters
a sr9.7 system that it can't write into /dev on, it takes what it
thinks is the next best place to put the crp mailboxes. You guessed
it, in "/tmp". 
    If you give the world "write" rights to "/dev" on your sr9.7 systems
then the "crp??" things will start accumulating in the "/dev" directory.
Under sr10.1 they would get recycled and would not accumulate, similar
to the sr9.7 crp mailboxes in `node_data. However it looks like you have
found a bug in sr10.2 that causes it to just keep creating new ones, not
recycle existing ones. I've checked it here, when I use a sr10.1 machine,
they don't accumulate but when I use a sr10.2 machine, they do. It looks
like they deserve an APR for this one.

Dave Funk