Re: sysAtReboot and epicsExit

[Andrew Johnson <anj@aps.anl.gov>]

Hi Chris,

Chris Slominski wrote:
> ld<systemO/system.munch
>
> sysAtReboot not found. epicsExit will not be called by reboot.
>
> We have converted from VxWorks 5.2 to 5.5, and from epics 3.13.3 to 
> 3.14.8.2 We get this diagnostic on startup of our IOCs when epics static 
> object constructors are executed. I assume epics is trying to register 
> some kind of shutdown handler. I am not familiar with sysAtReboot and 
> don’t know why it is missing. Is it a VxWorks function? We do have odd 
> problems on warm reboots and I suspect needed reboot hooks are not being 
> called. What do I need to do?

sysAtReboot() is a routine you need to add to your vxWorks BSP/boot 
image which provides a way to get around the fundamental design flaw 
that Wind River made with their rebootHook facility — that the hook 
routines are called in the same order that they are registered rather 
than in reverse order.  This means that the TCP/IP network stack shuts 
down before the application running on top of it ever gets notified, so 
it is not possible for the application to close any network connections 
nicely.  The sysAtReboot facility registers its rebootHook *before* the 
network stack gets initialized, so our epicsAtExit() routines now get 
called before the network gets taken off-line.

I described the BSP changes you need in this tech-talk message: 
http://www.aps.anl.gov/epics/tech-talk/2005/msg00004.php
If you have any questions about that code just let me know.

If you can't make those changes immediately, you can add this line to 
the top of your st.cmd scripts which will at least ensure that the 
epicsAtExit() routines get called, but they still won't be able to clean 
up any network sockets.
  rebootHookAdd(epicsExitCallAtExits)

- Andrew
--
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right.  When he states that something
is impossible, he is very probably wrong.  -- Arthur C. Clarke