showard@uccba.UUCP (Steve Howard) (06/23/87)
I am running SYSV R2 on an AT&T 3B2. I am attempting to run pathalias
(From the Jan 86 posting) without any luck. When I feed the whole
map to pathalias I get the following on standard error:
rehash into 2039
pathalias: rehash error
pathalias: cannot recover!
When PA is only fed a state or two it runs but says "you can't get there
from here" and lists several @ signs. But if I feed it all the "d."
files it fails.
Is there some kind of problem allocating memory? I tried running PA at
night with no load, and it crashed with about 1.5 Meg of memory free
and no swap space used!!!! (according to sar -r). At this poing I
figured that there was some sort of per-process-limit of memory usage.
My kernel and shm values are as follows:
4096 MAXUMEM max. pages in users virtual address space
4096 MAXMEM similair to above
1 MAXSC max number of pages swapped out (not documented by AT&T!!!)
1 MAXFC number of pages saved (not documented by AT&T)
131072 SHMMAX max shared mem seg size
100 SHMMNI shared memory identifiers
6 SHMSEG max attached shm seg per process
512 SHMALL max in use shared mem (not used according to Rel Notes)
All the parameters were changed up and down and even to the values suggested
in the manual (probably a mistake :-)). Nothing changed.
As a last resort I undefined MYMALLOC and tried again. No change.
Am I missing something here?? Any comments or suggestions would be
appreciated.
--
Steve Howard UUCP: {pyramid,philabs!phrimit-eddie}!uccba!showard
USPS: M.L. 130, Cincinnati, OH 45221john@uw-nsr.UUCP (John Sambrook) (06/23/87)
In article <1177@uccba.UUCP> showard@uccba.UUCP (Steve Howard) writes: > >I am running SYSV R2 on an AT&T 3B2. I am attempting to run pathalias >(From the Jan 86 posting) without any luck. When I feed the whole >map to pathalias I get the following on standard error: > >rehash into 2039 >pathalias: rehash error >pathalias: cannot recover! > >When PA is only fed a state or two it runs but says "you can't get there >from here" and lists several @ signs. But if I feed it all the "d." >files it fails. > >Is there some kind of problem allocating memory? I tried running PA at >night with no load, and it crashed with about 1.5 Meg of memory free >and no swap space used!!!! (according to sar -r). At this poing I >figured that there was some sort of per-process-limit of memory usage. There was a bug in our version of pathalias in function yylex() in file parse.y. There is a declaration of "char buf[BUFSIZ]" that needed to be made static as the contents of the buffer are used after the function has returned. You should check to see if this is the case in your version of pathalias. I found this bug when I ported pathalias to our Data General MV/10000 system; others have found it on the 3B series as well. Good luck. >Steve Howard UUCP: {pyramid,philabs!phrimit-eddie}!uccba!showard > USPS: M.L. 130, Cincinnati, OH 45221 -- John Sambrook Dial: (206) 545-7433 University of Washington WD-12 Inet: john@nsr.acs.washington.edu Seattle, Washington 98195 UUCP: uw-nsr!john
bob@acornrc.UUCP (Bob Weissman) (02/07/88)
I've been having problems with pathalias lately. This is the latest
version as distributed on the net.
Site 'iconet', for example, disappears without a trace from pathalias
output. It is listed in oliveb's map entry along with a dozen other
sites starting with 'ico' which appear just fine in pathalias output.
We talk to a site, orc.olivetti.com, which is not yet listed in the
official maps, so it appears in our path.local file thusly:
acornrc <orc>(DIRECT+FAST)
orc = orc.olivetti.com
orc .orc.olivetti.com
But although pathalias output shows
orc orc!%s
orc.olivetti.com orc!%s
it also shows
.orc.olivetti.com oliveb!orc!%s
for some reason. oliveb is the domain gateway for orc's parent domain,
.olivetti.com.
Does anyone have any ideas what's going on here?
Thanks,
--
Bob Weissman
Internet: bob@acornrc.UUCP
UUCP: ...!{ ames | decwrl | oliveb | apple }!acornrc!bob
Arpanet: bob%acornrc.UUCP@AMES.ARPAgreg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (02/21/88)
I can only help with one of the problems described here, so I waited to see if anyone could help him with both of them. Since nobody has, I'll explain the one that I can and hope someone else will offer the other. In article <590@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: >I've been having problems with pathalias lately. .... >Site 'iconet', for example, disappears without a trace .... I can't help with this problem; not enough information. >We talk to a site, orc.olivetti.com, which is not yet listed in the >official maps, so it appears in our path.local file thusly: > acornrc <orc>(DIRECT+FAST) > orc = orc.olivetti.com > orc .orc.olivetti.com He then observes that, although pathalias constructs a direct route to orc, it constructs a long path to the domain: > orc orc!%s > .orc.olivetti.com oliveb!orc!%s If you think about it, this is not a surprise. What the input says is that you can reach .orc.olivetti.com by going through orc, but that you shouldn't go directly through orc. Pathalias does this by creating a dummy node for the arc to <orc>, a node which has no neighbors. The domain name is just another node to pathalias, so it makes it a neighbor of the "real" orc. Thus, the path to the domain does not go through the dummy <orc>; in our example, it is oliveb!orc!.orc.olivetti.com!%s and in the post-processing for the output paths, names beginning with a dot are stripped out, giving the counter-intuitive output. The solution is to coerce pathalias into constructing links from the dummy <site>s to any other node that will engender a null output path. It would be ideal if pathalias would do this automatically, but I don't see any easy way of doing it; I can hear Peter screaming already. It might be possible to allow a specification like "<orc> .orc.olivetti.com" but that would be a manual and error-prone operation -- everybody who was the destination of a non-through-path link would have to know to include it. The real pity of this is that it negates a lot of the value of a link to uunet, since they list most (all?) of their links as non-through-path, so a gateway that signs up for better connectivity for their domain actually receives the benefit only for themselves and not for the whole domain.... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
bob@acornrc.UUCP (Bob Weissman) (02/23/88)
In article <2057@ncr-sd.SanDiego.NCR.COM>, greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: > I can only help with one of the problems described here, so I waited to > see if anyone could help him with both of them. Since nobody has, I'll > explain the one that I can and hope someone else will offer the other. > > In article <590@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: > >I've been having problems with pathalias lately. .... > >Site 'iconet', for example, disappears without a trace .... > > I can't help with this problem; not enough information. It turns out to be my own damn fault for running pathalias with the "-i" (fold all names into lowercase) switch. It turns out that recently, the Olivetti sites in Italy have banded together into a network called ICOnet; i.e., in the u.ita.1 file, there's an entry ICOnet = {iconet,icocae,icodap,...}!(LOCAL) By folding the *network* name ICOnet with -i, the *site* name iconet was lost. Moral: don't run pathalias with -i. I was confused because the man page claims -i folds "host names" into lowercase, and doesn't say anything about network names. And Greg's explanation of the other problem was correct. Peter Honeyman is considering a change to do what I (and others) want. (See the referenced articles if you're interested.) -- Bob Weissman Internet: bob@acornrc.uucp UUCP: ...!{ ames | decwrl | oliveb | apple }!acornrc!bob Arpanet: bob%acornrc.uucp@ames.arc.nasa.gov
honey@umix.cc.umich.edu (Peter Honeyman) (02/27/88)
regarding the iconet problem, it turns out there is (was?) a
declaration
ICOnet = {iconet, ...}
and the -i flag was being used. think about it. GIGO, no?
regarding the "terminal link to a domain" problem, well, yes, i didn't
think this through, and will fix it up when i get some time. (in a
nutshell, the penalty won't be applied to the domain, but to the host
members, which may be down the domain tree a fur piece -- i hate this
sort of hack, but vox populi, vox dei, right, besides, when rick adams
and greg noel say "jump" i say "how high?".)
on reflection, i did think it through -- it sez right there in the BUGS
section: "Terminal nets are not implemented." (a domain is a special
sort of net.)
(i know, "get off that sopabox, honeyman. i said JUMP, boy!")
peterhoney@umix.cc.umich.edu (Peter Honeyman) (02/27/88)
Bob Weissman writes: >It turns out to be my own damn fault for running pathalias with the >"-i" (fold all names into lowercase) switch. >... >Moral: don't run pathalias with -i. I was confused because >the man page claims -i folds "host names" into lowercase, and doesn't >say anything about network names. no! the -i flag should be the default, without a way to override it! host name comparisons should always be case insensitive, but this would be too costly -- strcmp is number five in my pathalias profiling hit list. although it weighs in at only 5% or so of run time, strcmp is called several hundred thousand times. i fear that a case- insensitive strcmp would would be much more costly, both because of the extra work it must do, and because it misses the assembler library routines common in most breeds of unix. so the -i flag is a compromise, but one i consider vital to proper behavior. i maintain that the ICOnet definition is brain-damaged, and should be fixed. i will, at your suggestion, fix the man page to eliminate the confusion. note that pathalias can't tell whether a name is a net or a host until all the input is consumed, e.g., thing host # it's a floor wax! thing = {a, b, c} # no, it's a dessert topping! peter