Subject | signal handing |
---|---|
Author | Nick Upson |
Post date | 2011-08-15T10:18:21Z |
Hi,
I have a C program daemon running under Centos using firebird 2.1.4 Classic
which can have long-running transactions.
I'm trying to sort out signal handling such that a SIGTERM (15) causes the
program to finish it's current transaction, commit and then exit, rather
than just exit immediately and potentially leave an uncommited transaction
to timeout
currently this doesn't happen, the signal appears to be handed on to the
fb_inet_server such that the current task cannot be committed
This is output from the program, which I'll try and explain
15.08.11 10:34:19 TDT19 Connecting to database
15.08.11 10:34:19 TDT1 ATTACH
15.08.11 10:34:24 TDD7 run 0
15.08.11 10:34:24 TDT6 START TRANSACTION
15.08.11 10:34:24 TDT8 EXECUTE EXECUTE PROCEDURE PR_LOOP_TRIG(0)
15.08.11 10:36:21 TDT9 retcode is 0, status_vector 1, 0
15.08.11 10:36:21 TDT13 COMMIT
15.08.11 10:36:21 TDD8 end 0
# to here is a normal execution, the prodecure (for testing) always take
around 2 mins to run
15.08.11 10:36:21 TDD7 run 1
15.08.11 10:36:21 TDT6 START TRANSACTION
15.08.11 10:36:21 TDT8 EXECUTE EXECUTE PROCEDURE PR_LOOP_TRIG(1)
# signal sent while procedure is running
15.08.11 10:37:20 ZZD1 signal_terminate 15
# signal noticed by signal handler function, just prints and sets a flag
15.08.11 10:38:19 TDT9 retcode is 0, status_vector 1, 0
# same retcode from isc_execute_immediate, same status vectors
15.08.11 10:38:19 TDT13 COMMIT
15.08.11 10:38:19 TDT14 Database error code - 335544528 trigger 1 timing
loop
# commit fails, code means "database shutdown"
[Non-text portions of this message have been removed]
I have a C program daemon running under Centos using firebird 2.1.4 Classic
which can have long-running transactions.
I'm trying to sort out signal handling such that a SIGTERM (15) causes the
program to finish it's current transaction, commit and then exit, rather
than just exit immediately and potentially leave an uncommited transaction
to timeout
currently this doesn't happen, the signal appears to be handed on to the
fb_inet_server such that the current task cannot be committed
This is output from the program, which I'll try and explain
15.08.11 10:34:19 TDT19 Connecting to database
15.08.11 10:34:19 TDT1 ATTACH
15.08.11 10:34:24 TDD7 run 0
15.08.11 10:34:24 TDT6 START TRANSACTION
15.08.11 10:34:24 TDT8 EXECUTE EXECUTE PROCEDURE PR_LOOP_TRIG(0)
15.08.11 10:36:21 TDT9 retcode is 0, status_vector 1, 0
15.08.11 10:36:21 TDT13 COMMIT
15.08.11 10:36:21 TDD8 end 0
# to here is a normal execution, the prodecure (for testing) always take
around 2 mins to run
15.08.11 10:36:21 TDD7 run 1
15.08.11 10:36:21 TDT6 START TRANSACTION
15.08.11 10:36:21 TDT8 EXECUTE EXECUTE PROCEDURE PR_LOOP_TRIG(1)
# signal sent while procedure is running
15.08.11 10:37:20 ZZD1 signal_terminate 15
# signal noticed by signal handler function, just prints and sets a flag
15.08.11 10:38:19 TDT9 retcode is 0, status_vector 1, 0
# same retcode from isc_execute_immediate, same status vectors
15.08.11 10:38:19 TDT13 COMMIT
15.08.11 10:38:19 TDT14 Database error code - 335544528 trigger 1 timing
loop
# commit fails, code means "database shutdown"
[Non-text portions of this message have been removed]