Re: caget: Identical process variable names on multiple servers

["J. Lewis Muir via Tech-talk" <tech-talk@aps.anl.gov>]

On 11/11, Guruswamy, Tejas wrote:
> The message you quoted (Warning: "Identical process variable names on multiple servers") is a warning and is not fatal. By itself it does not indicate that caget will return a non-zero status.

Hi, Tejas!

Thank you for your reply.

Interesting; I did not know that.

What I failed to include in the output is this line that came right
after the CA.Client.Exception lines:

----
Channel connect timed out: some PV(s) not found.
----

So, I'm sorry; I didn't realize that I left that off, and I just now
checked the script run log and saw it.  I'm guessing that that's likely
the reason that the exit status was nonzero.

It's still puzzling, though, because the warnings say that it's
connecting to 0.0.0.1:5 and 0.0.0.2:5, but then it gives the error about
channel connects having timed out.

> However the fact that it appeared once and then disappeared again suggests something had temporarily changed about your network configuration or access (a gateway started/stopped responding, a router forwarded something it usually doesn't, ...), which could be the underlying reason for the failure.

And that would be very difficult to track down.

> Did your message really refer to the ip:port 0.0.0.1:5 ?

Yes, and 0.0.0.2:5 for the second PV.

> Almost exclusively the 0.0.0.0/8 subnet is used by hosts which are trying to discover their correct address (for example, DHCP requests always come from 0.0.0.0). But I've never seen 0.0.0.1, nor an application intentionally running on port 5.

Yeah, I had similar thoughts.  Depending on context, 0.0.0.0 could have
a special meaning such as (1) any network address, (2) the default
route, (3) a null route (a.k.a. black hole) if configured as such, or
others noted in

  en.wikipedia.org/wiki/0.0.0.0

I also wondered whether maybe EPICS CA might use 0.0.0.0 as a special
address to indicate that it's unknown or something like that.

> Is it possible something had a momentary glitch and you got a corrupted packet? It would have to be something like the packet data being interpreted as the header. Not sure how that could happen and still pass checksums, but I also don't see how you can get that weird ip/port combo through any intentional network configuration.

Hmm, that's the problem; lots of things are possible. :-)  I have no
idea.

Thanks!

Lewis