From: JINMEI Tatuya Date: Thu, 11 Oct 2012 22:41:36 +0000 (-0700) Subject: [1858] cleanup: reorder log messages X-Git-Tag: trac2402_base~28^2^2~1^2~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2768eb3551fdaa2c4728563535dfb69f732dc033;p=thirdparty%2Fkea.git [1858] cleanup: reorder log messages --- diff --git a/src/bin/bind10/bind10_messages.mes b/src/bin/bind10/bind10_messages.mes index e8a2eb2ee5..6c3d12e229 100644 --- a/src/bin/bind10/bind10_messages.mes +++ b/src/bin/bind10/bind10_messages.mes @@ -167,6 +167,30 @@ so BIND 10 will now shut down. The specific error is printed. % BIND10_SEND_SIGKILL sending SIGKILL to %1 (PID %2) The boss module is sending a SIGKILL signal to the given process. +% BIND10_SEND_SIGNAL_FAIL sending %1 to %2 (PID %3) failed: %4 +The boss module sent a single (either SIGTERM or SIGKILL) to a process, +but it failed due to some system level error. There are two major cases: +the target process has already terminated but the boss module had sent +the signal before it noticed the termination. In this case an error +message should indicate something like "no such process". This can be +safely ignored. The other case is that the boss module doesn't have +the privilege to send a signal to the process. It can typically +happen when the boss module started as a privileged process, spawned a +subprocess, and then dropped the privilege. It includes the case for +the socket creator when the boss process runs with the -u command line +option. In this case, the boss module simply gives up to terminate +the process explicitly because it's unlikely to succeed by keeping +sending the signal. Although the socket creator is implemented so +that it will terminate automatically when the boss process exits +(and that should be the case for any other future process running with +a higher privilege), but it's recommended to check if there's any +remaining BIND 10 process if this message is logged. For all other +cases, the boss module will keep sending the signal until it confirms +all child processes terminate. Although unlikely, this could prevent +the boss module from exiting, just keeping sending the signals. So, +again, it's advisable to check if it really terminates when this +message is logged. + % BIND10_SEND_SIGTERM sending SIGTERM to %1 (PID %2) The boss module is sending a SIGTERM signal to the given process. @@ -305,27 +329,3 @@ the configuration manager to start up. The total length of time Boss will wait for the configuration manager before reporting an error is set with the command line --wait switch, which has a default value of ten seconds. - -% BIND10_SEND_SIGNAL_FAIL sending %1 to %2 (PID %3) failed: %4 -The boss module sent a single (either SIGTERM or SIGKILL) to a process, -but it failed due to some system level error. There are two major cases: -the target process has already terminated but the boss module had sent -the signal before it noticed the termination. In this case an error -message should indicate something like "no such process". This can be -safely ignored. The other case is that the boss module doesn't have -the privilege to send a signal to the process. It can typically -happen when the boss module started as a privileged process, spawned a -subprocess, and then dropped the privilege. It includes the case for -the socket creator when the boss process runs with the -u command line -option. In this case, the boss module simply gives up to terminate -the process explicitly because it's unlikely to succeed by keeping -sending the signal. Although the socket creator is implemented so -that it will terminate automatically when the boss process exits -(and that should be the case for any other future process running with -a higher privilege), but it's recommended to check if there's any -remaining BIND 10 process if this message is logged. For all other -cases, the boss module will keep sending the signal until it confirms -all child processes terminate. Although unlikely, this could prevent -the boss module from exiting, just keeping sending the signals. So, -again, it's advisable to check if it really terminates when this -message is logged.