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"