Determine if keyboard interrupt versus SIGINT trapped?

[Jibunnokage]

Determine if keyboard interrupt versus SIGINT trapped?

Not sure there is a way to determine this per se? Looked via Google for method, but the best I could find or rather think of was:

Trap SIGINT and KeyboardInterrupt via signal handler, and test if session is interactive, say via sys.__stdin__.isatty(). But this would not be completely accurate, because if SIGINT is sent to python (session, i.e. executing script) from somewhere else, it still might have been an interactive session versus called via cron or as service emulation under systemd. Adding a test to see if systemd active maybe? Such as if psutil.Process(os.getpid()).ppid() == 1? But that is still not 100% bullet proof, right?

[Gribouillis]

What is the use case for this?

[Jibunnokage]

I thought I explained that above, but to clarify, to determine the true source of the signal/interrupt, we have a situation where an operator can 'kill' the script while running interactive or via system unit file instance. As an audit control measure we want to be able within the script to tell the difference, if possible, if the SIGINT came from the operator or from monitoring control system. Thus, we want to know if Keyboard Interrupt was done or the SIGINT was from a our monitoring and control system, or if SIGINT was generated by a 3rd party source. Since we can track the SIGINT from the monitoring and control system, we need to still track KeyboardInterrupt or 3rd party source sending SIGINT. The auditors want the MOST details as possible, so the question was posted. Just saying any SIGINT or KeyboardInterrupt not from the monitor and control system, is too much of a catch all for our auditors, unfortunately. If I can prove, with reasonable effort, that there is not method available to avoid the catch all scenario, the auditors will compromise. This thread is part of the investigative effort to prove the is not a reasonable method to do as they requested, and the catch all concept will have to be accepted as best possible option at this time.

[Gribouillis]

I don't think Python can do that directly however, in C there is a function named sigaction() that gives information about the process that sent the signal. You could find ways of calling this function by writing a C extension that invokes sigaction() or by using the ctypes module.

[Jibunnokage]

I don't think Python can do that directly however, in C there is a function named sigaction() that gives information about the process that sent the signal. You could find ways of calling this function by writing a C extension that invokes sigaction() or by using the ctypes module.

Thank you for that information, that is likely what we all need to do.

[Gribouillis]

Actually somebody has already written a wrapper of sigaction() and sigqueue() with ctypes: there is a module signal2 in Pypi. It was uploaded in 2011 and I don't know if it will work for Python 3 but it looks worth trying.