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://people.web.psi.ch/adwan/
################################################
ì