Jeff,
> One way to guarantee that is to launch the ca repeater when
> Linux boots.
Right. This actually Cygwin, but the principle is the same.
> 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.
In this case the vendor file I/O is completely hidden from the application. It is not even returning a file handle. The vendor initialization routine reads a file, creates a number of temporary files, and downloads firmware to a PXI card. One of those files must be open when caRepeater starts, and later on it needs to be deleted, and that fails.
Mark
>
> 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/>
> >
> > ################################################
> >
> > ì
>
>
- Navigate by Date:
- Prev:
RE: autosave V4.1 and caRepeater Jeff Hill
- Next:
RE: autosave V4.1 and caRepeater Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: autosave V4.1 and caRepeater Jeff Hill
- Next:
RE: autosave V4.1 and caRepeater Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|