Display when SIGTERM received (or any signal, for that matter) in debug.log #1305

Useful for debugging bitcoin dealing with signals and exiting. Adds a line to debug.log when signal received.

ACK

Why receives HandleSIGTERM an integer? Seems unused in the diff.

Know your unix :-) signal handlers receive an integer with the signal number.

I'd make it "SIGTERM received", but otherwise ACK.

Unix != Diapolo :-D

@sipa or how about, considering that function will be run with any signal, displaying the signal number received..?

@sipa I've just realised this change is also in another pull request. :-s I've avoided saying SIGTERM received, as this is a specific signal (15), so saying that might be misleading, whereas it's true to say the function HandleSIGTERM() is called.

I'll close this pull request in favour of the other which includes this change and others.

HandleSIGTERM is apparently used for SIGTERM, SIGINT and SIGHUP.

Ah, named according to the principle of most surprise. Interesting :)

I suspect HandleSIGTERM would run if SIGUSR1 was sent too. Any signal other than 9, probably.

@rebroad no signal handler is installed for SIGUSR1. See the beginning of AppInit2 in init.cpp.

Since this was getting ACKs, I've re-opened it. It's more likely to get pulled than pull #1311, which it's a subset of. I should probably break #1311 into smaller pieces....

You should rebase this!

@Diapolo I can do... does it make much difference? (rebased now)

Yes, just take a look under https://github.com/bitcoin/bitcoin/pull/1305/commits what do you see :)? Use <pre>git fetch upstream</pre> <pre>git rebase upstream</pre> to ensure you have the current master as base.

@Diapolo I see 1 commit and 1 diff. What do you see? That's also what I saw before I rebased.

I saw 4 commits and 3 of which were not from you ;). Now I see a single one, which is good.

What stops this from creating a deadlock when a signal is received inside the "printf" replacement log function?

@luke-jr how exactly?

@sipa printf needs to use a lock to ensure multiple threads aren't writing at the same time, but signals can interrupt writes (while that lock is held). If this happens, the printf in the signal handler will try to lock again, and block. Even if the lock is recursive, there is a risk of the signal printf mixing output with the ongoing one.

Ouch. I keep forgetting that we redefine printf in a macro :-(

@laanwj You were updating the function a few days ago ^^...

@luke-jr what would be your ideal solution for this (other than removing the prinf)?

I think it might be safe to create a new thread just for the printf. Then the signal returns - locks get released on their normal schedule, etc - while the second thread waits to acquire whatever locks it needs to log.

@luke-jr when I get time I'll have a dabble with this. I'm fairly new to the whole thread thing, but I was thinking of moving ProcessBlock() into a thread of it's own so that it doesn't block the reception of messages (which it appears to do currently, based upon the timestamps in debug.log)

Creating a thread sounds like a terrible kludge. That the safest way is to save the "signal status" to a global variable in the signal handler and let the Shutdown function pick it up and print it. Python, for example, does signal handling in this way.

Btw, instead (or, in addition to) the numeric signal it should probably print the signal name, converted using strsignal.

@laanwj That does sound like a decent solution. I will update this to do that, when I get time...

NAK, possible deadlock. printf() obtains a lock, which can get really messy when signals are involved. You might even be inside the printf lock itself.

Maybe set a 'got_sigterm' boolean that triggers a print elsewhere...