0

As a follow up to this question, I am correct that (4) (quote below) is the farthest I can get ?

in my app (a .NET app which runs as a systemd daemon), intercept the kernel signal sent to the process upon running kill (perhaps calling sigaction) so to ignore the kill request.

And that with the disclaimer of it being possible only for cases when the user calls kill either omitting the signal number or using a trappable signal (like the default SIGTERM).
If the user calls kill with SIGKILL (-9) or any other non-trappable signal - this will also fall short.

Is the assumption above accurate ?

Veverke
  • 338
  • 3
  • 16

1 Answers1

2

Yes, this is quite normal. Many programs trap and handle their own signals. For example, it's common to:

  • trap SIGTERM, SIGINT, and/or SIGQUIT and then flush and close all open files and otherwise clean up & shut-down gracefully, instead of just dying.
  • trap SIGHUP and reload config files, and/or close & re-open all log files. or just treat SIGHUP similarly to SIGTERM.
  • trap and handle other trappable signals as appropriate - that's what they're for, after all...for other processes to send signals to a running program. It's up to the signal-receiving process to deal with them or just ignore them (possibly having a default result like being killed for SIGTERM if unhandled), according to the programmer's requirements.
cas
  • 1
  • 7
  • 119
  • 185