resource-agents/SOURCES/bz1937429-azure-lb-redirect...

119 lines
3.7 KiB
Diff

From 760680df771b6e2a9fbcd2f6d9862df4ec1a86de Mon Sep 17 00:00:00 2001
From: Reid Wahl <nrwahl@protonmail.com>
Date: Tue, 9 Mar 2021 18:25:52 -0800
Subject: [PATCH 1/2] azure-lb: Be quiet during stop operation
Currently, it logs "kill (<pid>) No such process" to stderr during stops.
A stop operation is expected to run `kill -s 0 $pid` for a nonexistent
PID, so log that at debug level.
A start or monitor operation's `kill -s 0 $pid` should always succeed,
so any output is unexpected and an error.
Also remove "local" bashism.
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
---
heartbeat/azure-lb | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/heartbeat/azure-lb b/heartbeat/azure-lb
index 65a12235b..863132744 100755
--- a/heartbeat/azure-lb
+++ b/heartbeat/azure-lb
@@ -93,12 +93,18 @@ getpid() {
lb_monitor() {
if test -f "$pidfile"; then
- if pid=`getpid $pidfile` && [ "$pid" ] && kill -s 0 $pid; then
- return $OCF_SUCCESS
- else
- # pidfile w/o process means the process died
- return $OCF_ERR_GENERIC
+ [ "$__OCF_ACTION" = "stop" ] && level="debug" || level="err"
+
+ if pid=$(getpid "$pidfile") && [ -n "$pid" ]; then
+ output=$(kill -s 0 "$pid" 2>&1)
+ mon_rc=$?
+
+ [ -n "$output" ] && ocf_log "$level" "$output"
+ [ "$mon_rc" -eq 0 ] && return $OCF_SUCCESS
fi
+
+ # pidfile w/o process means the process died
+ return $OCF_ERR_GENERIC
else
return $OCF_NOT_RUNNING
fi
@@ -131,7 +137,7 @@ lb_start() {
}
lb_stop() {
- local rc=$OCF_SUCCESS
+ stop_rc=$OCF_SUCCESS
if [ -n "$OCF_RESKEY_CRM_meta_timeout" ]; then
# Allow 2/3 of the action timeout for the orderly shutdown
@@ -160,7 +166,7 @@ lb_stop() {
while :; do
if ! lb_monitor; then
ocf_log warn "SIGKILL did the job."
- rc=$OCF_SUCCESS
+ stop_rc=$OCF_SUCCESS
break
fi
ocf_log info "The job still hasn't stopped yet. Waiting..."
@@ -168,7 +174,7 @@ lb_stop() {
done
fi
rm -f $pidfile
- return $rc
+ return $stop_rc
}
lb_validate() {
From 10f39e90d6b04c28752a4f9adc94dfc03d9d61b8 Mon Sep 17 00:00:00 2001
From: Reid Wahl <nrwahl@protonmail.com>
Date: Tue, 9 Mar 2021 18:32:45 -0800
Subject: [PATCH 2/2] azure-lb: Redirect stdout and stderr to /dev/null
This fixes a regression introduced in commit d22700fc.
When the nc listener process created by an azure-lb resource attempts to
write to stdout, it dies with an EPIPE error.
This can happen when random/garbage input is sent to the nc listener, as
may happen during a port scan. For example, if the listener is on port
62000, and a client sends some text (e.g., `echo test | nc node1
62000`), then the listener attempts to echo "test" to its stdout. This
fails with an EPIPE.
Prior to commit d22700fc, all output was redirected to the pid file.
This caused its own problems, but it prevented this particular behavior.
The fix is to redirect the listener's stdout and stderr to /dev/null.
Resolves: RHBZ#1937142
Resolves: RHBZ#1937151
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
---
heartbeat/azure-lb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/heartbeat/azure-lb b/heartbeat/azure-lb
index 863132744..ade1b4577 100755
--- a/heartbeat/azure-lb
+++ b/heartbeat/azure-lb
@@ -119,7 +119,7 @@ lb_start() {
if ! lb_monitor; then
ocf_log debug "Starting $process: $cmd"
# Execute the command as created above
- $cmd &
+ $cmd >/dev/null 2>&1 &
echo $! > $pidfile
if lb_monitor; then
ocf_log debug "$process: $cmd started successfully, calling monitor"