Subject: |
RE: Changing caRepeaters |
From: |
[email protected] (Jeff Hill) |
Date: |
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
- Navigate by Date:
- Prev:
Changing caRepeaters Geoff Savage
- Next:
EPICS meeting before ICALEPCS-99 Matthias Clausen
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Changing caRepeaters Geoff Savage
- Next:
Re: Changing caRepeaters Chris Larrieu
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|