Re: softIOC and SIGHUP

[Ralph Lange <Ralph.Lange@bessy.de>]

 Hello Dmitry,

I agree that it generally would be better to check the SIGHUP handling 
before changing it.
Did you try if changing that behavior fixes the issue you are seeing?

It would be great if you opened a bug report against the Launchpad bug 
tracker for EPICS Base [1] to report this issue. (And maybe even file a 
patch if you were able to fix it.) Thanks a lot!

Also, is there any particular reason to not run the IOC inside a wrapper 
like procServ [2]? That would remove the need to use nohup in the first 
place.

Thank you,
Ralph

[1] https://bugs.launchpad.net/epics-base/+filebug
[2] https://sourceforge.net/projects/procserv/


On 17.09.2010 18:53, Dmitry Teytelman wrote:
> Hello all,
>
> Hello,
>
> I am running into a puzzling problem with a softIOC on Linux. The IOC
> is running on fairly standard x86 PC hardware under a custom Linux
> distribution (buildroot/busybox/uclibc/base-3.14.11). The IOC is
> normally started with /usr/bin/nohup, so that one can ssh to the unit,
> restart the IOC and disconnect. This worked very well until I've
> transitioned from older linuxthreads to NPTL. Now the IOC dies when it
> gets SIGHUP, even when started under nohup.
>
> A bit of digging showed that the IOC installs a handler and unblocks
> SIGHUP when it calls epicsSignalInstallSigHupIgnore() during iocInit.
> It seems to me it might be better to check first if SIGHUP is ignored
> and only modify settings if it isn't.