It would be lovely if one could configure IDA with a signal handler such that when IDA receives SIGTERM, it performs a save operation and a clean close of the IDB.
The use-cases are rather niche, but I somehow find myself in situations where it would help. Perhaps it could be opt-in if it’s considered undesirable or damaging by some users.
Three examples of use-cases:
- Due to display “issues” unrelated to IDA (e.g. display server is hung), unable to cleanly save and exit
- Due to display being physically inaccessible, but still able to run shell commands (a session running at the office, but not able to go to the office - only able to reach the system via SSH)
- An unexpected clean reboot (which, in Linux, begins by sending SIGTERM to all processes)
For each of these cases, one ends up with an “unpacked” database, something that is handled better in newer versions of IDA, but still to be avoided.
A SIGTERM handler would address all of the cases. Something like a SIGUSR1 handler would handle the manual signal cases but not the “unexpected reboot” case. I’d be happy to have either.
Alternative approaches or existing solutions
I’m aware of an auto-save/auto-snapshot plugin that saves IDB snapshots every X minutes. This is probably the best workaround currently. The drawbacks are it’s a lot of unnecessary I/O, and it will be an arbitrary interval set ahead of time, not an on-demand or just-in-time mechanism.
I don’t think it’s a good idea to create a third-party plugin that uses the signal handling method since signal handling is a very low level and complex thing in asynchronous C++ applications, though it may be technically possible. To avoid complexity, it would perhaps be simpler to leverage inotify to monitor a directory for a file like “ida-save-” or some hacky thing.
Not a major priority for me, just a nice-to-have, and I appreciate all the real feature development that has gone on, especially since the 8.0 release.