Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Mon, 20 Sep 2010 13:23:04 -0400

 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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System