Re: RFC: add a mechanism to call epicsExit when signals are received

[Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>]

On 03/04/2025 22:32, Michael Davidsaver via Tech-talk wrote:
> On 4/3/25 06:17, Jure Varlec via Tech-talk wrote:
>> On 4/3/25 11:34, Michael Davidsaver via Tech-talk wrote:
>>> wrt. your attached epicsSignalExit.cpp, the method
>>> epicsSignalExit::getInstance()
>>> is not async safe since (depending on c++ version) it will run the
>>> class
>>> epicsSignalExit constructor.
>
> To be clear, I like the idea that eg. systemd+procServ could
> trigger a clean exit.  I just had a past bad experience with
> a library unconditionally installing/replacing signal handlers.
>
> fyi. have a look at epicsSignal.h for the limited management
> currently possible with libCom.
>
>> I don't think that's the case. The signal handler is run only if it
>> is first registered using epicsExitOnSignal(), presumably from iocsh.
>> getInstance() is first used there, which constructs the static
>> object. The next invocation of getInstance() (from the signal
>> handler) will not run the contructor.
>
> True, my mistake.
>
>
>> If this feels icky to you, there might be another approach. Have a
>> global bool specifying whether this feature is enabled or not. The
>> iocsh command then only sets this flag. Thread creation and handler
>> registration is done at IOC init, if the flag is set.
>
> The existing global constructors/destructors in libCom occasionally
> cause problems, and I would like to see them removed.  So imo. adding
> another seems counterproductive.


As I understand it, it's not a global constructor, since it will only be
called when epicsExitOnSignal is called; the C++ feature I'm depending
on here is that static objects inside functions are guaranteed to have
their initialization synced between threads, if two threads call
epicsExitOnSignal simultaneously. I don't know what destructors for
static objects look like, though.


I understand if you prefer more explicit initialization, anyway.


>
> https://urldefense.us/v3/__https://github.com/epics-base/epics-base/issues/286__;!!G_uCfscf7eWS!dYXoRGfIz5VngL5KqDx1QwaTsAFBAWPpH_F7hMKcSH79eGAQ_GCLu55dr24IbJSnowSV9Dy2t5qHzRBIb0eGROOuVQ$
>
> I suppose it might also be acceptable to install and remove
> a handler with initHook callbacks.
>
>
>> Érico, I don't have the time right now to look deeper into this, but
>> I would love to see something like this because it would make
>> managing IOCs via Systemd more straightforward, not to mention making
>> compulsive use of C-c to terminate IOCs nicer. Thanks for pushing
>> this forward!


I'm glad to hear the need is shared by others!


>
> For reference, compulsive use of ctrl+d has this effect today.
> (closing stdin triggers a return from "iocsh(NULL)" )


I initially thought this would only work for POSIX,
because epicsExitCallAtExits is registered with atexit(), but the IOC
main function actually calls epicsExit! That's great.


>
> It might be fun to teach procServ to try this before signaling.


That could be useful! Sort of as alternative to the --killsig option, I
suppose? There's a bug we noticed with procServ at LNLS where even
though the killsig setting is respected, SIGKILL is sent almost
immediately afterwards anyway; it's something we haven't had time to fix
yet, but it did affect the systemd+procServ integration, requiring a
non-trivial setup.

For my current use case, I used procServ with --noautorestart and the
service had KillSignal=SIGINT. When the service is stopped, procServ
ignores SIGINT, but the IOC receives it, executes its signal handler and
exits. Then, TimeoutStopSecs passes, and systemd sends SIGKILL to the
whole control group, which now consists of procServ.

Alternatively, once the procServ bug is fixed, we could keep the
KillSignal=SIGTERM default, use KillMode=mixed and pass --killsig=15 or
--killclosestdin, so that procServ kills the IOC, waits for it to exit,
and, if TimeoutStopSecs expires for some reason, systemd kills the whole
control group. I believe using KillMode=mixed instead of
KillMode=process is better, because it avoids the possibility of
accidentally leaving some process laying around. This also requires the
addition of a --killwait or similar option to procServ, so it can wait
some time before sending the final SIGKILL, or (maybe better) a
--nosigkill option.


>
>
>
> Also, I recall that the linux-specific "prctl(PR_SET_PDEATHSIG, ...)"
> has be used to build cleanup on exit mechanisms which work even
> for abnormal termination.
>


Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.