Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Tue, 15 Jun 1999 17:15:18 -0600

Geoff,

While on this subject I should add that "CA repeater" related problem 
has been recently discovered under HPUX by Ralph Lange at BESY. If a CA 
client process discovers that the CA repeater isn't running then it takes 
it upon itself to spawn the repeater using "exec()". It turns out 
however that "exec()" inherits any open files of the process that calls 
"exec()". It appears that we did not discover this problem under Solaris 
because Solaris closes all server socket files when "exec()" is called,
and HPUX does not. In any case, the solution was to close all open files 
which are not required by stdio before calling exec(). This fix has been 
committed to CVS, but has not been applied as a patch against R3.13.1. 
I can back patch R3.13.1 if there is interest.

> Now that I have built EPICS host I would like to change the executing
> caRepeaters with the ones I have built.  I don't think this is
> absolutely necessary.  My understanding is that channel access from
> R3.12 and R3.13.1.  However I believe the exercise will teach me some
> important aspects of channel access.  So here are the questions.
> 

It should not be required to restart the repeater process.

> How do I determine which process is the caRepeater process?  I'd like
> to base the search on the port number since I know this.  Our previous
> installation did not start caRepeater automatically so the name could be
> anything.  For more info on this see the discussion in startCArepeater.

The repeater process's name will be "caRepeater" unless the repeater 
executable was not in the path when it was spawned. Otherwise the 
repeater inherits the parent process's name, and a warning message
is dumped as follows. 

		ca_printf("!!WARNING!!\n");
		ca_printf("The executable \"%s\" couldnt be located\n", pImageName);
		ca_printf("because of errno = \"%s\"\n", strerror(errno));
		ca_printf("You may need to modify your PATH environment variable.\n");
		ca_printf("Creating CA repeater with fork() system call.\n");
		ca_printf("Repeater will inherit parents process name and resources.\n");
		ca_printf("Duplicate resource consumption may occur.\n");

I am open to input on this particular behavior. Perhaps it would be best
to just not spawn the repeater in this particular situation.

Note that rebooting the UNIX host is a simple, if draconian, way to 
guarantee a repeater restart. Otherwise, it is actually quite difficult 
to determine the process that is using a particular port under Solaris. 
If you know how please send the details! I was able to trace this through 
with great difficulty under vxWorks many years ago, but it required 
winding through raw dumps of multiple kernel level data structures.

> 
> How do other sites start caRepeater?  It seems to me that it should be
> started when the machine boots.

There are Solaris scripts that can be run when the host boots in your 
EPICS bin installation directory. See rc2.caRepeater.

> 
> Are there any utilities to assist in debugging channel access problems?
> I have used tcpdump on a Digital Unix host.
> 

I have used tcpdump, etherfind (sunos4), and snoop(solaris). So far, they
have been sufficient for my needs. We will also be trying one of the 
commercial GUI based packages for the PC here at some point.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System