Bug 806028

Okay so the workaround is to modify the startup script and force it to never return failure when PID does not exist.

Then I will have to cherry pick also the second workaround that waits until PostgreSQL socket is ready, because initial database creation could also potentionaly fail:

https://bugzilla.redhat.com/show_bug.cgi?id=802346

Pushing upstream:

c5f0990 806028 - postgres sysvinit script workaround

This workadound basically removes the if statement from the postgresql init script.

+  # RHBZ 800534 for RHEL 6.x - pg sysvinit script return non-zero ...
+  exec { "fix-pgsysvinit":
+    path        => "/usr/bin:/bin",
+    onlyif      => "grep '\"x\$pid\" != x' /etc/init.d/postgresql",
+    command     => "sed -i 's/\"x\$pid\" != x/1 = 1/g' /etc/init.d/postgresql"
+  }

I have reopened bug for RHEL 6.4+ so we could remove this workaround in next major release: https://bugzilla.redhat.com/show_bug.cgi?id=800534

Setting depends on.

FYI, I saw something similar happen when timing out trying to start... httpd or tomcat6 or something. Re-running katello-configure worked just fine.

@Corey - if you hit it again please report. We had similar issue with Candlepin (db initialization), but this should be resolved too.

Actually found my old log:

err: /Stage[main]/Candlepin::Service/Exec[wait for candlepin]/returns: change from notrun to 0 failed: /usr/bin/wget --spider --tries 10 --retry-connrefused --no-check-certificate https://localhost:8443/candlepin/ returned 8 instead of one of [0] at /usr/share/katello/install/puppet/modules/candlepin/manifests/service.pp:10

Again, rerunning worked. But I haven't seen it occur since. Will obviously bug it if it returns.

@Corey - that is another issue, we should have a BZ on that (VERIFIED), maybe to reopen it.

Currently trying to tackle/test this; I've been experimenting with adding sleep statements (e.g., "sleep 5s") in various locations within the start/restart functions of the postgresql initscript, but I'm looking for more detail as to whether this would be sufficient to exercise the functionality.

Testing notes:  

In addition to the above, I've attempted to do the following - used the lines below script to run at the point when puppet was looking for the open postgresql connections.

  
iptables -A OUTPUT -p tcp --destination-port 5432 -s 127.0.0.1 -j DROP
iptables -L -v
echo Sleeping...
sleep 6s
iptables -A OUTPUT -p tcp --destination-port 5432 -s 127.0.0.1 -j ACCEPT

rather, this is the corrected script

iptables -A OUTPUT -p tcp --destination-port 5432 -s 127.0.0.1 -j DROP
iptables -L -v
echo Sleeping...
sleep 6s


after tailing the logfile and noticing it wait on postgres, i reenabled the port by restarting iptables (w/o the rule listed above).

End result was that puppet waited accordingly for postgresql to start up.

I've tried exhaustively to repro this, and short of ending up with a real-world scenario where I can see it take place in a repeatable manner, I'd posit that this has been tested as thoroughly as possible.

Marking QA Verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0661.html