5 ms·
Might be a good idea to send the process a SIGQUIT if you can, first, so you can dissect the ram image without worrying that the process will finish before you
by gumby 2y ago
Might be a good idea to send the process a SIGQUIT if you can, first, so you can dissect the ram image without worrying that the process will finish before you do.
- wizzwizz4 2y agoSIGSTOP might be better, in this case. Either way, the specific approach described in the article requires a running Python session.
- gumby 2y agoSIGQUIT gives you a core dump which you can peruse / scrape at your leisure. This is funny because normally I consider core dumps to be a barbaric relic of the card deck days. Core dumps are literally a shadow of what was going on so you have to guess. In the mid 70s I was debugging crashed processes by attaching to them with all network connections, files etc all open so I could frob them and figure out what was going. Then again, ITS used the a debugger as its "shell" so was ultra hacker friendly. This should still be the default, but most POSIX systems can't even support it.
- wizzwizz4 2y agoSIGQUIT can be ignored, e.g. with: # handle SIGQUIT appropriately (readable version) __import__('signal').signal(3, 1) SIGSTOP just happens, and is mostly transparent (unless you handle SIGCONT, but who does?).
- NikkiA 2y agoor use gcore which will save the core without terminating the process