2

We know that - aside from SIGKILL and SIGSTOP - a program can intercept IPC signals, and run its internal handler circumventing the operation of the default handler.

I can think of at least one very good reasons for doing this with the SIGINT signal.

  • Namely implementing a signal handler that executes either a last ditch backup, saves a memory dump, or writes to log, before reverting to the default signal operation that terminates the process.

I can also think of a good reason why a piece of malware might catch and block SIGINT:

  • Namely to extend the execution time of the process . For the majority of users,CTRL+c is the go to keyboard shortcut for most terminal users and there are many that are unaware of CTRL+z (SIGTSTP which only stops the process, which remains among terminal jobs), not to mention CTRL+\ , which sends the SIGQUIT and creates a core dump.

  • If CTRL+c gets caught and blocked, such users will likely try to open another terminal window, and run something along the lines of :

    ps aux | grep [process name]

    get the process PID, and execute the SIGKILL with

    kill -9 [$PID]

  • Similarly, users connecting to a terminal session on a remote machine, will attempt to make a second connection with a new terminal session, and go through a similar process/PID search in order to terminate the culprit. Obviously, this tactic might extend the process runtime by only a short period, but even extra 3 minutes of a file transferring process using a high bandwidth connection of 10MB/s will transfer almost 2 GB of additional data, so there is certainly some merit to it.

However, recently I have noticed - perhaps only because I started paying attention to it - that there are programs that seemingly fall into another subset.

  • These programs, which are open-source and have packages maintained and examined closely enough that hiding a major piece of malware code seems highly unlikely.

  • They do not take control of keyboard input like vim and other text editors

  • They have internal handlers that catch SIGINT and ignore it completely. There is no eventual process termination and to the best of knowledge no last ditch critical tasks are attempted.

My question:

Is there a possible reason why a process might choose to intercept but drop SIGINT completely for a legitimate purpose?

In other words, can there be a good reason (from a code or system standpoint) or situation when catch and ignore of SIGINT is more advantageous than its known default operation that would terminate the running process?

  • 1
    An example of such a program would be nice to see. – Kusalananda Mar 5 at 18:31
  • 1
    @BarBar1234 have you considered that that may be a bug rather than some great conscious decision? I didn't have the pleasure to use the Kodi player, but SIGINT is probably starting the same slow close process as trying to close it from the menu. – mosvy Mar 5 at 18:38
  • 2
    Well since your best example is not an example and does not ignore the signal this question seems to be founded upon a fallacy. – JdeBP Mar 5 at 18:40
  • 1
    @BarBar1234 that code is using signal-unsafe code in signal handlers, and that's all that should be said about it ;-) – mosvy Mar 5 at 19:10
  • 1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.