1

My PostgreSQL service must start after OpenVPN, and when I check the order rc.X directories they are listed as S16openvpn and S19postgresql, so they are in the right order.

However connecting to a database via the VPN fails and the logs always indicate that PostgreSQL could not bind at startup. My guess is that it takes some time for all the OpenVPN services to start and PostgreSQL is started before the loading of the OpenVPN networks is complete.

Is there a way for the PostgreSQL to try to reload and attempt to bind to the OpenVPN network before before giving up?

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
vfclists
  • 1,632
  • 5
  • 22
  • 37

3 Answers3

4

It seems to me you're trying to bind postgres to an IP associated with the tunnel. If that's the case, the ip_nonlocal_bind is the solution to your problems. Setting the ip_nonlocal_bind allows you to bind to any IP, even one not associated with your computer, which is exactly what you want when you want to bind to an IP you don't yet have - for instance when using virtual IP's that floats between active and passive nodes.

Assuming this is ipv4 only;

echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

Or throw it into /etc/sysctl.conf

net.ipv4.ip_nonlocal_bind
3molo
  • 4,330
  • 5
  • 32
  • 46
2

This is my workaround which I used a lot of time in these situations: edit the postresql rc.d starting script and add a delay with the sleep bash command. I know this is not so clean maybe anyone got any better solution.

0wn3r
  • 866
  • 1
  • 8
  • 21
0

Scrap the 2 separate startup scripts, and just make one that calls both of them in the right sequence, with whatever depending logic you like

Doug
  • 1