Experimental Physics and
Industrial Control System

I have not been able to figure out why this problem apparently
goes away when autosave's status PV's are loaded.  Autosave calls
ca_context_create() regardless of whether or not status PV's exist,
and it makes CA connections to lots of PV's in any case.

It must be the save_restore thread that's issuing the fork()
call, since this thread does all of save_restore's CA work.
Here's the slightly simplified calling sequence:
   st.cmd calls create_monitor_set()
   create_monitor_set() calls epicsThreadCreate("save_restore")
   save_restore() calls ca_context_create()

Is there some way I can prevent the save_restore thread from having
that file open, or if not would it be better to spawn it as a task
instead of a thread?

--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab

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?

Replies:

Re: autosave V4.1 and caRepeater Andrew Johnson

Navigate by Date:

Prev: Re: UDP to CA_UDP hangs network? Steven Hartman

Next: Re: autosave V4.1 and caRepeater Andrew Johnson

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 Andrew Johnson

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