RE: autosave V4.1 and caRepeater

["Jeff Hill" <johill@lanl.gov>]

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:ahed.aladwan@psi.ch]
Sent: Friday, October 21, 2005 1:07 AM
To: 'johill@lanl.gov'; 'mooney@aps.anl.gov'
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://people.web.psi.ch/adwan/                  

################################################

ì