#!/bin/bash

# Set datagram receiving queue length to 128 for haproxy's socket
sysctl net.unix.max_dgram_qlen=128

# We are intentionally not using exec so we can reload the haproxy config later
echo "Running command: '${CMD}'"
$CMD

# TODO(SamYaple): This has the potential for a race condition triggered by a
#                 config reload that could cause the container to exit
while [[ -e "/proc/$(cat /run/haproxy.pid)" ]]; do
    sleep 5
done

# Based on the above loop this point should never be reached
exit 1

#!/bin/bash
# We are intentionally not using exec so we can reload the haproxy config later
echo "Running command: '${CMD}'"
$CMD

# TODO(SamYaple): This has the potential for a race condition triggered by a
#                 config reload that could cause the container to exit
while [[ -e "/proc/$(cat /run/haproxy.pid)" ]]; do
    sleep 5
done

# Based on the above loop this point should never be reached
exit 1

--- 
+++ 
@@ -1,4 +1,8 @@
 #!/bin/bash
+
+# Set datagram receiving queue length to 128 for haproxy's socket
+sysctl net.unix.max_dgram_qlen=128
+
 # We are intentionally not using exec so we can reload the haproxy config later
 echo "Running command: '${CMD}'"
 $CMD
Fix false alert messages in HAProxy logs

Bug #1549753 raises false alarm about haproxy to the operator and
monitoring tools even though haproxy is running fine and there is
no issue.

haproxy uses UDP datagram socket for logging and the default queue
length of 10 datagrams causes false alert messages in haproxy
logs. This patch set fixes this bug by increasing the queue length
to 128.

Test results of the fix in this patch set are at
http://paste.openstack.org/show/490302/.

Change-Id: I64fdd17cd278d51616aa0dfa4e8d2a422c8ee630
Closes-Bug: #1549753
