EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA client on unix bug
From: Andrew Johnson <[email protected]>
To: Till Straumann <[email protected]>
Cc: TECHTALK tech-talk <[email protected]>
Date: Mon, 11 Jun 2007 11:31:28 -0500
Hi Till,

Till Straumann wrote:
I found the following problem (tested on
linux, solaris, base-3.14.9, base-3.14.8.2)
with the CA client on unix:

Partly confirmed on linux-x86 (Fedora-5) against R3.14.9 as follows:


  uranus% cau
    cau:  get no_PV
  **** 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.
  error on search for no_PV
  couldn't open no_PV
    cau:

While cau is still running, a ps from another terminal gives this:

  uranus% ps -ef | grep cau
  anj       1440  2430  0 09:45 pts/7    00:00:00 cau
  anj       1444  1440  0 09:45 pts/7    00:00:00 [cau] <defunct>
  anj       1446  2428  0 09:45 pts/6    00:00:00 grep cau

In my case though, the <defunct> process' parent is still the original cau thread, and when the parent exits so does the defunct thread. Any long-running CA client application should be usable to prove this.

In libCom/osi/os/posix we can fix the problem using Till's fix of having osiSpawnDetachedProcess() call _exit() which is a Posix.1 routine. Both vxWorks and RTEMS just return osiSpawnDetachedProcessNoSupport so there's no issue there; the other implementations of osiSpawnDetachedProcess() are for VMS and WIN32, neither of which call exit().


Another problem though appears to be that at no point does the CA client library actually fork off a caRepeater itself, even after this message appears:


  CA client library is unable to contact CA repeater after 50 tries.
  Silence this message by starting a CA repeater daemon
  or by calling ca_pend_event() and or ca_poll() more often.

I proved that as follows: With caRepeater running, I can find the following output from netstat (NB: ca-2 is the IANA official name for our port on recent OS releases; on older releases you may have to use 5065 instead - look in your /etc/services file to see whether you have ca-1 and ca-2 defined):

uranus% netstat -a | grep 'ca-2'
udp 0 0 *:ca-2 *:*



With cau running as above there is no output from that command. Was this functionality removed intentionally Jeff?


- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

Replies:
Re: CA client on unix bug Till Straumann
References:
CA client on unix bug Till Straumann

Navigate by Date:
Prev: Linux PMAC PCI driver & device support available Philip Taylor
Next: RE: IK320 problem Shepherd, EL (Emma)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: CA client on unix bug Till Straumann
Next: Re: CA client on unix bug Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·