Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 21 Oct 2005 08:59:43 -0600

> The only solution I have come up with is to be certain that caRepeater is
> already running before I start my EPICS application.

One way to guarantee that is to launch the ca repeater when Linux boots.

> The problem with this is that my EPICS application calls vendor supplied
> libraries that open, close and delete files.  I have no control over their
> source code, and they don't do FD_CLOEXEC in their code.

Sometimes a vendor library will have a backdoor routine returning the file
descriptor associated with some externally visible handle. If they have that
you could set FD_CLOEXEC from user code. Suspect however that you have
already looked for this.

Jeff

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Friday, October 21, 2005 8:43 AM
> To: Jeff Hill; Aladwan Ahed; [email protected]
> Cc: [email protected]
> Subject: RE: autosave V4.1 and caRepeater
> 
> Jeff,
> 
> The problem with this is that my EPICS application calls vendor supplied
> libraries that open, close and delete files.  I have no control over their
> source code, and they don't do FD_CLOEXEC in their code.  This is leading
> to serious problems, in that there is a file open in their code which they
> try to close and delete, but cannot because caRepeater has it open.
> 
> The only solution I have come up with is to be certain that caRepeater is
> already running before I start my EPICS application.
> 
> Mark
> 
> 
> ________________________________
> 
> From: Jeff Hill [mailto:[email protected]]
> Sent: Fri 10/21/2005 9:37 AM
> To: 'Aladwan Ahed'; [email protected]
> Cc: [email protected]
> Subject: RE: autosave V4.1 and caRepeater
> 
> 
> 
> Hello Ahed,
> 
> 
> 
> > epics> exit
> 
> > [root@pc5697 iocCCD]# whouses /dev/video1394/0
> 
> > 809 caRepeater
> 
> 
> 
> I have attached the code in EPICS base that spawns off the CA repeater in
> EPICS V4 on POSIX systems. Note that this code does not attempt to close
> any files in the duplicate process created with fork. In the past we
> closed all files other that stdin/stdout/stderr in the duplicate process
> prior to calling exec, but there were complaints that this was too
> intrusive. The current approach is to let the OS close any open files that
> have the close-on-exec flag set.
> 
> 
> 
> So you need only set the FD_CLOEXEC just after you open /dev/video1394/0
> to avoid the behavior that you observe.
> 
> 
> 
> I updated the CA reference manual (see attached).
> 
> 
> 
> Jeff
> 
> 
> 
> epicsShareFunc osiSpawnDetachedProcessReturn epicsShareAPI
> osiSpawnDetachedProcess
> 
>     (const char *pProcessName, const char *pBaseExecutableName)
> 
> {
> 
>     int status;
> 
> 
> 
>     /*
> 
>      * create a duplicate process
> 
>      */
> 
>     status = fork ();
> 
>     if (status < 0) {
> 
>         return osiSpawnDetachedProcessFail;
> 
>     }
> 
> 
> 
>     /*
> 
>      * return to the caller
> 
>      * if its in the initiating process
> 
>      */
> 
>     if (status) {
> 
>         return osiSpawnDetachedProcessSuccess;
> 
>     }
> 
> 
> 
>     /*
> 
>      * since all epics sockets are created with the FD_CLOEXEC
> 
>      * option then we no-longer need to blindly close all open
> 
>      * files here.
> 
>      */
> 
> 
> 
>     /*
> 
>      * overlay the specified executable
> 
>      */
> 
>     status = execlp (pBaseExecutableName, pBaseExecutableName, NULL);
> 
>     if ( status < 0 ) {
> 
>         fprintf ( stderr, "**** The executable \"%s\" couldn't be
> located\n", pBaseExecutableName );
> 
>         fprintf ( stderr, "**** because of errno = \"%s\".\n", strerror
> (errno) );
> 
>         fprintf ( stderr, "**** You may need to modify your PATH
> environment variable.\n" );
> 
>         fprintf ( stderr, "**** Unable to start \"%s\" process.\n",
> pProcessName);
> 
>     }
> 
>     exit ( -1 );
> 
> }
> 
> 
> 
> The caRepeater process seems to have possesion of my file or device
> 
> 
> 
> Do you notice that if the caRepeater is started by your process then the
> file that your application has open in your process is also now open in
> the caRepeater process?
> 
> 
> 
> The code that spawns the caRepeater on POSIX systems does not attempt to
> close any files in the duplicate process created with fork() and then
> exec(). In the past we closed all open files other that
> stdin/stdout/stderr before calling exec(), but there were complaints that
> this was too intrusive. The current approach is to close no files, and
> assume that the OS will close any open files that have the close-on-exec
> flag set.
> 
> 
> 
> The bottom line: you need only set the FD_CLOEXEC when you open your file
> (device) to avoid the caRepeater's taking possesion of your file (device).
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Aladwan Ahed [mailto:[email protected]]
> Sent: Friday, October 21, 2005 1:07 AM
> To: '[email protected]'; '[email protected]'
> Subject: autosave V4.1 and caRepeater
> 
> 
> 
> Hi Tim and Jeff,
> 
> 
> 
> I have noticed a strange behavior that I want to share with you when using
> autosave v4.1 for EPICS 3.14.7.
> 
> 
> 
> I use the utility to restore parameters for a Firwire EPICS server running
> at Linux fedora core 1, kernel 2.4
> 
> 
> 
> Problem:
> 
> 
> 
> When the autosave status pv's are not loaded (or not defined through
> save_restoreSet_status_prefix()) it will complain with the msg:
> 
> 
> 
> Can't connect to status PV(s) for list 'auto_settings.save'
> 
> 
> 
> If the EPICS server is terminated, it don't kill it self properly and
> keeps hanging around using -in my case - /dev/video1394/.
> 
> 
> 
> epics> exit
> 
> [root@pc5697 iocCCD]# whouses /dev/video1394/0
> 
> 32261 ../../bin/linux-x86/ieee1394 ./st.cmd
> 
> 
> 
> When caRepeter is in the path and not already started, it will start and
> attach it self to the epics server process and ultimately to the
> /dev/video1394, then you see:
> 
> 
> 
> epics> exit
> 
> [root@pc5697 iocCCD]# whouses /dev/video1394/0
> 
> 809 caRepeater
> 
> 
> 
> When I start the Firewire server again, it fails as the /dev/video1394 is
> till used by another process, and I need to force kill the previous epics
> process before I can restart the Firewire server again.
> 
> 
> 
> Solution:
> 
> 
> 
> 1-       The problem disappeared by loading the status pv's and define the
> autosave prefix. I managed to reproduce the problem every time so far.
> 
> 2-       If you don't care about the status PVs, be sure that caRepatear
> is already started before you start the autosave service.
> 
> 
> 
> 
> 
> Further Test:
> 
> 
> 
> I suspected that my application might have a thread that don't terminate
> properly, so I only built the server using autosave, I stopped caRepetar
> and I took away it from the path, I started the server, and then
> terminated it (exit), still when I list the processes I see:
> 
> 
> 
> [root@pc5697 iocCCD]# ps auxw |grep st.cmd
> 
> root     10736  0.0  0.2  9996 2432 pts/0    S    08:14
> 0:00 ../../bin/linux-x86/ieee1394 ./st.cmd
> 
> root     10745  0.0  0.0  4488  584 pts/0    S    08:15   0:00 grep st.cmd
> 
> 
> 
> 
> 
> Is that an expected behavior?
> 
> 
> 
> Cheers,
> 
> Ahed
> 
> 
> 
> ##########################################
> 
> # Ahed Aladwan
> 
> # SLS Controls / Paul Scherrer Institute
> 
> # WSLA/208, 5232 Villigen PSI Switzerland
> 
> # Tel:+41 56 310 4594
> 
> # Fax:+41 56 310 4413
> 
> # www.psi.ch <http://www.psi.ch>
> 
> # http://people.web.psi.ch/adwan/ <http://people.web.psi.ch/adwan/>
> 
> ################################################
> 
> ì

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System