Hi,
this also got no answer so far, but deserves one.
On Wed, May 12, 2021 at 10:02:30PM +0200, Matthias May via Openvpn-devel wrote:
> We recently updated OpenVPN to 2.5.2 and found that the PID
> is since [1] unconditionally deleted when OpenVPN exits.
Right.
> This breaks OpenVPN in our init.
Sorry for that.
> We relied on this file to get the PID to be able to check if the process
> actually started, or something went wrong during init, or to see if the
> process died sometime later.
>
> One could argue that the absence of the PID file is indication enough that
> the process
> doesn't exist anymore, but that doesn't hold up when there are multiple
> instances running.
I do argue that way, and the "multiple instances running" argument does
not convince me - if you have multiple instances, they must have unique
PID files anyway, so you can see if "openvpn_instance4.pid" exists or not.
So, at startup, you can have 3 situations
- openvpn started normally, PID exists, process exists
- openvpn exited (planned or error exit), PID does not exist
- openvpn crashed (core dump-style), PID exists, process does not exist
this is fairly easy to figure out whether a given instance started up fine.
> Once the process died we used the PID to look in the syslog for clues as to
> why the process died,
> and present the user with an error message based on that.
>
> Can you please revert this unconditional deletion of the file?
> Or do you see any alternative to get the PID of a process that
> exits immediately (case of misconfiguration)?
This depends on how you start these instances - if you start them without
--daemon, and call wait() in the caller, you get the PID of whoever exited
back. If you use systemd, with named instances, it will tell you in
the journal (by instance named).
To find a certain instance in syslog (if you have no systemd), you can also
use the "--syslog instance1234" trick - so each instance would send its own
identifier, and you can look for "instance1234[" in syslog.
But generally speaking, a process that is ending normally (and we consider
"error exit" to be "ending normally", as opposed to "SIGSEGV core dump
boom") should not end with any resources still in use - so, tun interface
and routes are cleaned up, pid file is removed, auth_control_files are
removed, etc. - and we really believe in "cleaning up". OpenVPN did not
always do the right thing (especially cleaning up interfaces on error
exit), but we're getting there.
Again, sorry that we caused work here.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
