Adding inittab respawn rule for openvpn server

m.ardito

Hi,

I have a debian 7.6 server (still using systemV init) running openvpn server, it works well as system service but I would like to make it restart automatically if, for any reason, the service crashes.

the service regularly starts/stops using
# service openvpn start|stop

I never used such a feature before, so I did the usual searches, and found this
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

but after trying a lot of different /etc/inittab lines, I gave up.
KIlling the service-initiated process with kill -9, the service never comes up again.
I have to start it manually from the shell.

first, I tested a command line command that works, it starts the vpn with the right config:
#/usr/sbin/openvpn --cd /etc/openvpn --config /etc/openvpn/server.tun.conf

ok, then added this line, to /etc/inittab, in several flavours:

eg, using a /etc/inittab line like
----------------------
OV:2345:respawn:/usr/sbin/openvpn --cd /etc/openvpn --config /etc/openvpn/server.tun.conf
----------------------

or, creating a script and trying to run that through the shell:
----------------------
OV:2345:respawn:/bin/bash /etc/openvpn/respawn.sh
----------------------
being /etc/openvpn/respawn.sh:
----------------------
#!/bin/bash
/usr/sbin/openvpn --cd /etc/openvpn --config /etc/openvpn/server.tun.conf
----------------------

it never works.

in the syslog I always find, instead:
----------------------
Jul 7 10:40:41 altvpn init: Id "OV" respawning too fast: disabled for 5 minutes
----------------------

Can someone shed some light to make this work?

Thanks,
Marco

TinCanTech

This works for me:

/etc/inittab

v1:2345:respawn:/etc/init.d/openvpn start

which respawns the openvpn service.

It still throws init: Id "v1" respawning too fast: disabled for 5 minutes every 5 minutes .. but openvpn is restarted

m.ardito

TinCanTech wroteThis works for me:
/etc/inittab
v1:2345:respawn:/etc/init.d/openvpn start
which respawns the openvpn service.
It still throws init: Id "v1" respawning too fast: disabled for 5 minutes every 5 minutes .. but openvpn is restarted

Thanks, ...it was the only thing I didn't try... but now I did, and it still does not restart openvpn.

nothing in the logs, except the same message you get, about every 5 minutes.

I test it like this:
- add the line
- reboot the server
- while the service is operating normally, i "kill -9" its pid.
Then nothing happens.

The command "/etc/init.d/openvpn start" works, on the shell, current runlevel is 2, respawn line in /etc/inittab (last line in file) is
"V1:2345:respawn:/etc/init.d/openvpn start"

last syslog lines:
=====================
Jul 13 08:55:13 srvvpn ntpd[2409]: peers refreshed
Jul 13 08:59:35 srvvpn init: Id "V1" respawning too fast: disabled for 5 minutes
Jul 13 08:59:35 srvvpn ntpd[2409]: Listen normally on 7 tun0 10.8.0.9 UDP 123
Jul 13 08:59:35 srvvpn ntpd[2409]: peers refreshed
Jul 13 09:00:01 srvvpn /USR/SBIN/CRON[3393]: (root) CMD (/root/test/checker.sh)
=====================

Should it work? What else can be checked?

TinCanTech

m.ardito wroteI test it like this:
- add the line
- reboot the server
- while the service is operating normally, i "kill -9" its pid.
Then nothing happens.

You realise you will have to wait for the respawn to occur .. It is not immediate.

m.ardito

...I guess I waited a few minutes... I'll try to wait more...
but I have a feeling that it's not starting, for some reason...

m.ardito

...damn, you were right, I was wrong... after a while (maybe one minute), it was restarted...
that syslog lines about disabling for 5 minutes were so strange...

TY

Marco

TinCanTech

I duckduckgo'd "respawning too fast" and found this ..

http://unix.stackexchange.com/questions/257147/why-does-init-disable-the-process-if-its-respawning-too-fast

vonbrand wroteinit(8) is just a dumb program, it doesn't care if ...

I think it a little more like dumb and dumber ..
The message appears to be logged on success or failure so make of that what you will ..

I recommend updating to a newer init system and not get left behind.
Migration to systemd may have upset some Linux purists but I find it quite good.

Anyway, thanks for letting us know it worked 8-) .. in the end.