OpenVPN signals to systemd that it is ready before the VPN connection is up

Describe the bug
OpenVPN sends the READY=1 sd_notify message to systemd once it has completed initialisation, before the VPN tunnel is established. This means that systemd units that depend on the VPN connection being up by ordering themselves after the OpenVPN unit will fail.

To Reproduce
Broad outline:

1. Create a systemd unit for an OpenVPN connection
2. Create a systemd unit that can only succeed once the OpenVPN connection is up, and order it after the OpenVPN unit with Requires= and After=
3. Start the second unit. Note that it fails.

My specific scenario has CIFS mount and automount units; the mount will only succeed if the VPN has connected. The trimmed-for-simplicity unit config looks like this:

/etc/systemd/system/openvpn-pdnet.service:

[Unit]
After=network.target
Description=OpenVPN instance ‘pdnet’

[Service]
ExecStart=openvpn --suppress-timestamps --config <file>
Restart=always
Type=notify

/etc/fstab:

//example.org/Directory /mnt cifs rw,credentials=/etc/creds,x-systemd.automount,x-systemd.mount-timeout=60s,nofail,x-systemd.requires=openvpn-pdnet.service,x-systemd.after=openvpn-pdnet.service 0 0

Expected behavior
OpenVPN does not signal to systemd that it is ready until the VPN connection is actually up, so that systemd units configured to only start after the OpenVPN unit can safely rely on the connection being available.

Version information:

• OS: NixOS 24.05
• OpenVPN version: 2.6.12

Additional context
The current behaviour is deliberate, and was introduced by e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae in 2017; before that commit the behaviour I'd like was in place. Given this is deliberate behaviour, I'm opening this report to discuss whether we want a fix; the fix itself is pretty straightforward assuming there's consensus that this is actually a bug.

There are three justifications given in the commit message for that change:

• "First, it adds challenges if --chroot is used in the configuration; this is already fixed."

  I don't use --chroot so I'm not quite sure what the challenges are, but if they've already been fixed then they presumably don't need this fix as well?

• "Secondly, it will cause havoc on static key p2p mode configurations where the log line above ["Initialization Sequence Completed"] will not happen before either sides have completed establishing a connection"

  I also don't use these configurations, and I don't have a sense of what havoc this causes. But it seems correct to me that the OpenVPN client would not report itself as ready to systemd before the connection has been established.

• "And thirdly, if a client configuration fails to establish a connection within 90 seconds, it will also fail. For the third case this may
  not be a critical issue itself, as the host just needs to get an Internet access established first - which in some scenarios may take much longer than those 90 seconds systemd grants after the OpenVPN client configuration is started."

  I do understand this issue, but I think this is the wrong solution. Or at least it's the wrong solution now; it may well be that systemd didn't have better options when this change was made in 2017. The point of reporting that a unit is ready is that systemd knows the unit can be used and other units that depend on it can run. If it's taking a long time for OpenVPN to fully establish a connection, it's correct that systemd should know and be able to act on that situation.

  If this is causing problems, the correct solutions IMVHO are either (a) setting a longer timeout before systemd declares the unit has failed, using TimeoutStartSec=, or (b) where there is some other blocking requirement like Internet access, to order the OpenVPN unit after that access has been established, e.g. by specifying Wants=network-online.target and After=network-online.target.

As I say, I definitely don't understand the ramifications of at least two of the problems outlined above, and I could well believe I don't fully appreciate the third either. Nonetheless, being able to order one systemd unit after another is exactly what the READY=1 notification is intended for, and this functionality is broken with the current OpenVPN code. At the very least, I'd like the behaviour to be configurable.

I have a patch more-or-less ready to go for what I consider to be the preferable behaviour, and I'm currently running OpenVPN with that patch in place.

Review the existing READY=1 sd_notify path and commit e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae first; the issue names no source file or test. Resolve whether readiness should be delayed until the VPN tunnel is established or made configurable, then verify that dependent systemd units start only after the connection is available.