systemd: Move the READY=1 signalling to an earlier point
PATCH 1/1 systemd: Move the READY=1 signalling to an earlier point
Currently, OpenVPN will first tell systemd it is ready once the log will be appended with "Initialization Sequence Completed". This turns out to cause some issues several places.
First, it adds challenges if --chroot is used in the configuration; this we already fixed. Secondly, it will cause havoc on static key p2p mode configurations where the log line above will not happen before either sides have completed establishing a connection. 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 need to be a critical issue, as the host just needs to get an Internet access established first - which in some scenarios may take much longer than those 90 seconds after the OpenVPN client configuration tries to start.
The approach this patch takes is to consider OpenVPN ready once all the initial preparations and configurations have happened - but before a connection to a remote side have been attempted. This also removes the need for specially handling the --chroot scenario.
The final "Initialization Sequence Completed" message update is kept (though slightly simplified) to indicate we're in a good state - even though that update will still not be visible if --chroot is used (as before this patch).
Trac: #827, #801
--- src/openvpn/init.c | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-)
src/openvpn/init.c +10 -19
@@ -562,6 +562,15 @@ context_init_1(struct context *c) }#endif +#ifdef ENABLE_SYSTEMD +/* We can report the PID via getpid() to systemd here as OpenVPN will not +* do any fork due to daemon() a future call. +* See possibly_become_daemon() [init.c] for more details. +*/ +sd_notifyf (0 ,"READY=1\nSTATUS=Pre-connection initialization succesfull\nMAINPID=%lu" , + (unsigned long )getpid ()); +#endif + }void
@@ -1042,24 +1051,6 @@ do_uid_gid_chroot(struct context *c, bool no_delay) {if (no_delay) { -#ifdef ENABLE_SYSTEMD -/* If OpenVPN is started by systemd, the OpenVPN process needs -* to provide a preliminary status report to systemd. This is -* needed as $NOTIFY_SOCKET will not be available inside the -* chroot, which sd_notify()/sd_notifyf() depends on. -* -* This approach is the simplest and the most non-intrusive -* solution right before the 2.4_rc2 release. -* -* TODO: Consider altnernative solutions - bind mount? -* systemd does not grok OpenVPN configuration files, thus cannot -* have a sane way to know if OpenVPN will chroot or not and to -* which subdirectory it will chroot into. -*/ -sd_notifyf (0 ,"READY=1\n" -"STATUS=Entering chroot, most of the init completed successfully\n" -"MAINPID=%lu" , (unsigned long )getpid ()); -#endif platform_chroot (c->options.chroot_dir); }else if (c->first_time)
@@ -1409,7 +1400,7 @@ initialization_sequence_completed(struct context *c, const unsigned int flags)else {#ifdef ENABLE_SYSTEMD -sd_notifyf (0 ,"READY=1\nSTATUS=%s\nMAINPID=%lu" , message, (unsigned long )getpid ()); +sd_notifyf (0 ,"STATUS=%s" , message);#endif msg (M_INFO ,"%s" , message); }
Signature · 1 line
2.11.0
Hi,
Quoted 4 lines · David Sommerseth
The approach this patch takes is to consider OpenVPN ready once all the initial preparations and configurations have happened - but before a connection to a remote side have been attempted. This also removes the need for specially handling the --chroot scenario.
[..]
Quoted 2 lines
Trac: #827, #801
Signed-off-by David Sommerseth <[email protected]...>
I think this is a reasonable approach for the time being, until we have worked out a more fine-grained notification mechanism.
So, ACK.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...David Sommerseth <[email protected]...> on Wed, 2017/01/25 00:23:
Quoted 8 lines
Currently, OpenVPN will first tell systemd it is ready once the log will be appended with "Initialization Sequence Completed". This turns out to cause some issues several places.
[...]
Trac: #827, #801
Signed-off-by David Sommerseth <[email protected]...>
I am pretty sure people will complain that units depending on [email protected]... unit can no longer rely on an established connection. That said the line of argumentation is still valid and changes to solve this have been discussed in IRC channel. So for the time being...
ACK.
Signature · 3 lines
main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];)
putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I took the liberty to improve the commit message a little bit, to make a few things clearer.
Your patch has been applied to the following branches
commit e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae (master) commit 041fd6488434b5df01f86dd873b536a2b690ee13 (release/2.4)
Author: David Sommerseth Date: Wed Jan 25 00:23:44 2017 +0100
systemd: Move the READY=1 signalling to an earlier point
Trac: #827, #801
Signed-off-by: David Sommerseth <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Acked-by: Christian Hesse <[email protected]...>
Message-Id: <[email protected]...>
URL: https://www.mail-archive.com/[email protected]/msg13945.html
Signed-off-by: David Sommerseth <[email protected]...>- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJYiPJxAAoJEIbPlEyWcf3yxH4QALLTpJeE7AYS5N+54cRbswIM Qjw/rKIU5WUe7hf6R//H8HmsWWbhCddYMYojl1XRcLglUdGFm+fTWkTUIUAtEZIy F9IeTQNVRBYKXoJ5pVWs+9MfCKrdP7tuaUOouqmpuaU3EUwOTwXb9jfDhdNmiQFP bbE3LC5uv4/BMUK/nPWX/9bqfiUhRRhoOIgDeLBaz2opvBNhLzx4wZV5EPXIsHG0 i1/BKmaU4nlBtVdC0CnL3fuKo1rjoAM+gPqZK1RbZISOBuXXuSJPx9hbNwaY1tU9 Vnvzd4iGmDdjBmxRkjgCwtYcwGGSPR5CCTa0xttqBFAj9Ljp2ZkQECPMWHWbY2D5 3/nj1RhY//YV6iWQD4dgq/Xtnfhp5c9bW00vl8t3h7psiO1BbkrRyQBMvGX7McwS BvrgXhL0b8E5YLYM45ZQfYeCeNHXlZRlAIVEV0eC6ZHvFKqkVlhsjDHMzwztgbyF tydEp8vDQtpixIMccUDPtYdWx5OXEje/sR0394tymYwCoMlak4lF4ED2PXdzzkHB Lf41uTgoGUFhw3qbEaIhhTvbRCYq/AfSi7ojn46zhVqy6YPUG6F5WC4oHRlrvB63 OgGDtN2+F4loKXCOnbMPGM0eT3TKx11ft/fwnCJuVH6RVW3hybanGEXr3wkvWy6C B/PEIq+CSxztTxxY49OI
=dvhT
-----END PGP SIGNATURE-----