Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 21 Oct 2005 09:42:48 -0500

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