1

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?

9
  • 2
    An example of such a program would be nice to see. – Kusalananda Mar 5 '19 at 18:31
  • 2
    @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 '19 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 '19 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 '19 at 19:10
  • 1
    github.com/xbmc/xbmc/issues/15677 – JdeBP Mar 5 '19 at 19:14
2

As you've found, the most likely reason for a program to ignore SIGINTs is a bug. Well-behaved programs should respect signals, and typically a SIGINT means "please exit", but that's not required behavior. It is entirely within a program's right to use SIGINT for its own purposes. In a similar vein SIGHUP is used by many programs (daemons, typically) to mean "reload configuration files" instead of "your controlling terminal has hung up".

  • A long-running program or daemon might use SIGINT to mean "interrupt the current thing I'm working on, and move on to the next task".
  • A program that waits for an event might use SIGINT to mean "stop waiting for [event] and proceed" (SIGTERM would presumably mean the alternative "stop waiting for [event] and terminate").
  • Signals are often sent to multiple processes; if a program has reason to believe it wasn't the intended recipient it might ignore it.
  • A program might (correctly or incorrectly) believe it knows better than you and simply ignore interruptions and other optional signals in order to continue what it's working on; a critical task like a disk-repair process might reasonably ignore a user's request to stop part-way, for example.

Of course whether a program should handle SIGINT differently, for these reasons or any other, is debatable. It's likely to surprise or confuse users like yourself that expect the program to exit reasonably quickly. Therefore a well-behaved program that's considering handling SIGINT in an unusual way should ensure this behavior will make sense in context for (most) users.

This article (linked from Wikipedia), goes into great detail about SIGINT and proper handling, and discusses a number of edge-cases worth considering when implenting SIGINT handling.

2
  • Downvoter, any feedback? – dimo414 Oct 14 '20 at 21:31
  • I got the same downvote for asking the original question, but you certainly get my upvote for the answer (as well as the answer mark), sorry it took so long. – Neticegear Oct 15 '20 at 2:22

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.