On 10/02, 肖麟阁 via Tech-talk wrote:
> when the program is running, the console shows:
>
> ---
>
> searching ...
> **** The executable "caRepeater" couldn't be located
> **** because of errno = "No such file or directory".
> **** You may need to modify your PATH environment variable.
> **** Unable to start "CA Repeater" process.
> some channels not found yet
> reading ...
> some values not received
> Beam current (not found): 6.95269e-310
> Gap (not found): 2.0737e-317
>
> ---
>
> i don't find some documents about the caRepeater. i don't konw if i can ignore the error.
For an explanation of what caRepeater is, see the The CA Repeater
section of the CA Reference Manual
https://epics.anl.gov/base/R3-15/6-docs/CAref.html#Repeater
If caRepeater is not already running, the CA library will attempt to
start it. (IMO, this behavior is a bad idea; the CA library should not
attempt to start this executable. But it has been this way for a long
time.)
The solution is to either ensure that caRepeater is on the command
search path of the Eclipse RCP application (e.g., ensure that the path
of the directory that contains caRepeater is in the PATH environment
variable or some other equivalent that controls the command search
path) or start it before executing your Eclipse RCP application.
A sad thing about the former is that the caRepeater process started
by the CA library will continue to run as the user the Eclipse
RCP application ran as even after the Eclipse RCP application has
terminated.
I recommend the latter. In EPICS 3.15, there is a systemd
caRepeater.service unit file
https://github.com/epics-base/epics-base/blob/3.15/src/ca/client/caRepeater.service@
which gets installed to
bin/<os>-<arch>[-<toolset>/caRepeater.service
You could use that to start caRepeater at system boot as a system
user, and then your Eclipse RCP application would not need to worry
about ensuring that the path to caRepeater is on the command search
path. However, doing this means that caRepeater needs to already be
running on whatever machine your Eclipse RCP application runs on. So,
if you intend to deploy it as a binary application, you would also need
to ensure that the systemd caRepeater.service unit file is installed
and that caRepeater is started (or whatever appropriate method to
ensure caRepeater is started at system boot). Another approach would
be to just check that caRepeater is running as part of your Eclipse
RCP application's start-up, and if not, exit with an error saying
that it must be running. I suppose you could also start caRepeater
as the current user and then attempt to stop it when your Eclipse RCP
application exits. But this is still close to the existing design that
I'm not a fan of where the CA library starts caRepeater as the current
user. It's just a bizarre design that caRepeater would be running
as the user that started your Eclipse RCP application, and other CA
processes that have nothing to do with your Eclipse RCP application
depend on it and trust it.
Lewis
- Replies:
- CA Repeater Re: [EXTERNAL] Re: write a CA client by API in Eclipse Kasemir, Kay via Tech-talk
- References:
- write a CA client by API in Eclipse 肖麟阁 via Tech-talk
- Re: write a CA client by API in Eclipse Johnson, Andrew N. via Tech-talk
- Re: Re: write a CA client by API in Eclipse 肖麟阁 via Tech-talk
- Navigate by Date:
- Prev:
Re: EPICS base missing header files when using INSTALL_LOCATION Ralph Lange via Tech-talk
- Next:
CA Repeater Re: [EXTERNAL] Re: write a CA client by API in Eclipse Kasemir, Kay via Tech-talk
- 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:
Re: write a CA client by API in Eclipse Jemian, Pete R. via Tech-talk
- Next:
CA Repeater Re: [EXTERNAL] Re: write a CA client by API in Eclipse Kasemir, Kay via Tech-talk
- 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
|