Re: autosave V4.1 and caRepeater

[Tim Mooney <mooney@aps.anl.gov>]

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 (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab


Aladwan Ahed wrote:
> 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?