I believe this is the same bug I filed for Mandriva 2011. https://qa.mandriva.com/show_bug.cgi?id=64817 I have an OpenVPN configuration that requires I enter a password in order to connect to my office vpn. However, I am not sure the requirement for a password is the issue. I think the REAL issue is just that the openvpn service does not start. [root@localhost andy]# service openvpn start Starting openvpn (via systemctl): Failed to issue method call: Unit openvpn.service failed to load: Invalid argument. See system logs and 'systemctl status openvpn.service' for details. [root@localhost andy]# systemctl status openvpn.service openvpn.service Loaded: error (Reason: Invalid argument) Active: inactive (dead) The syslog does not contain any information about trying to start openvpn! I am not seeing any failure warnings there. It is almost like the service is not even attempting to start. No trace of trying to create a tun device. Note that I CAN load openvpn manually. As I reported in the Mandriva 2011 bug: /usr/sbin/openvpn /etc/openvpn/myconffile.conf works just fine with Mageia 2. Please fix this. Not being able to use the openvpn service is a show stopper for many users!
Hello same problem here with mageia 2 i586, the problem is not the password. As read somewhere else, the problem is that openvpn startup script is not compatible with the systemd compatibility layer. In order for /etc/init.d/openvpn to start, you need to add this line at the start of the script : SYSTEMCTL_SKIP_REDIRECT=1 With this, openvpn starts without error. But I'm still unable to get it to start automatically at boot, even if the correct links are present in /etc/rc3.d for example. I think an update is needed for mageia, this is a very useful package for people accessing corporate networks from home for example.
CC: (none) => npomaredeHardware: x86_64 => All
see https://bugzilla.redhat.com/show_bug.cgi?id=744244 and https://bugzilla.redhat.com/show_bug.cgi?id=752774
Keywords: (none) => UPSTREAMSource RPM: (none) => openvpn, systemd
CC: (none) => dlucio, mageia
The configuration of openvpn in mageia 2 has changed. Whatever your config file is (e.g. myconffile.conf should be used as an instance within an openvpn service unit under systemd. e.g. you should check "systemctl status openvpn@myconffile.service" or "systemctl enable openvpn@myconffile.service". This should have all converted automatically. You should NOT use SYSTEMCTL_SKIP_REDIRECT=1. It is deliberate that the openvpn sysvinit script does not run as the native, templated systemd unit does work correctly. So, please check the above commands and see what results you get. It should have converted fine on upgrade from previous Mageia (I did test the upgrade processes).
Hello, I have a similar issue, but it's more a startup sequence problem I think. I have 3 openvpn configuration files in /etc/openvpn. Systemctl shows me 3 services, called openvpn@conf1.service , etc ... But they all fail to start at computer boot. I have following message (extract) in /var/log/messages: Aug 12 11:43:08 arcadia openvpn[3014]: OpenVPN 2.2.2 x86_64-mageia-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Apr 28 2012 Aug 12 11:43:08 arcadia openvpn[3014]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Aug 12 11:43:08 arcadia openvpn[3014]: LZO compression initialized Aug 12 11:43:08 arcadia openvpn[3014]: TCP/UDP: Socket bind failed on local address 192.168.111.1:5007: Cannot assign requested address Aug 12 11:43:08 arcadia openvpn[3014]: Exiting It looks like it is started before the local IP address is actually assigned to my network interface. After boot is complete, I can restart them manually, and it works correctly. The network interface a bridge that is configured statically (no network manager), via the legacy file /etc/sysconfig/network-scripts/ifcfg-br0 : DEVICE=br0 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.111.1 NETMASK=255.255.255.0 GATEWAY=192.168.111.250 METRIC=10 MII_NOT_SUPPORTED=yes USERCTL=yes DNS1=192.168.111.1 DNS2=192.168.111.250 DOMAIN="local" RESOLV_MODS=yes IPV6INIT=no IPV6TO4INIT=no TYPE=Bridge NM_CONTROLLED=no
CC: (none) => albator78
@ François: It seems that for whatever reason the network-up.service is not running. This service ensures that the network is ready before moving on to start related services. Just do "systemctl enable network-up.service" and you should be good.
(In reply to comment #5) > @ François: It seems that for whatever reason the network-up.service is not > running. This service ensures that the network is ready before moving on to > start related services. Just do "systemctl enable network-up.service" and you > should be good. Hello, thanks for your answer. Alas, the "network-up" service was already enabled, and enabling it again does not solve my problem. "systemctl enable network-up.service" says "network-up.service is not a native service, redirecting to /sbin/chkconfig" But when I watch my computer boot, it looks like openvpn starts before any legacy "/etc/rc.d/init.d" scripts is run.
@ François: Hmm that's strange Can you supply the output of: systemctl show network-up.service | grep Before= and systemctl show openvpn@foo.service| grep After= (replace foo with your instance name) In theory openvpn@*.service should start *after* network.target and network-up.service should start *before* network.target which means that network-up has to start before openvpn@.service. Can you also do a fresh boot and run "systemd-analyze plot >boot.svg" then upload the boot.svg file? You will need to install the systemd-tools package.
Created attachment 2644 [details] Boot.svg (to find openvpn problem) Hello, the network-up and openvpn services look good: # systemctl show network-up.service | grep Before= Before=network.target nss-lookup.target lisa.service shutdown.target single.service multi-user.target graphical.target # systemctl show openvpn@mpx.service| grep After= After=syslog.target network.target systemd-journald.socket basic.target On the 'boot.svg' diagram, I do not see the "network-up.service" at all, but it looks like "network.target" starts simultaneously with "network.service", but the former takes several seconds to start, whereas the latter is immediatly operational.
Hmm, it looks suspiciously like network-up.service is, for some reason, simply being ignored. Let's find out why. Firstly: 1. ls -1 /etc/rc?.d/*network-up 2. (as root) systemctl enable network-up.service 3. ls -1 /etc/rc?.d/*network-up 4. chkconfig --add network-up 5. ls -1 /etc/rc?.d/*network-up 6. chkconfig --levels 2345 network-up on 7. ls -1 /etc/rc?.d/*network-up If all of that if any of the odd numbered steps gives you a link called/etc/rc3.d/S50network-up in the output, then stop, but let me know which command actually worked. Of course if it exists in step 1 then there is a different problem, and the output of "systemctl show network-up.service" would be appreciated. Hope that's easy enough to follow :)
First step: $ ls -1 /etc/rc?.d/*network-up /etc/rc0.d/K50network-up@ /etc/rc1.d/K50network-up@ /etc/rc2.d/K-1network-up@ /etc/rc2.d/S-1network-up@ /etc/rc2.d/S50network-up@ /etc/rc3.d/K-1network-up@ /etc/rc3.d/S-1network-up@ /etc/rc3.d/S50network-up@ /etc/rc4.d/K-1network-up@ /etc/rc4.d/S-1network-up@ /etc/rc4.d/S50network-up@ /etc/rc5.d/S50network-up@ /etc/rc6.d/K50network-up@ /etc/rcS.d/K-1network-up@ /etc/rcS.d/S50network-up@ This is strange, there are many "-1" numbered links ... This happens with some other services too ! So I did: find /etc/rc.d/ -name "*-1*" -delete Then I rebooted, and it finally worked. I guess the existence of any "K*" script will prevent execution of the "S*" script by systemd. I don't know from where these "-1" links came from, I know they've been around for a long time, but afaik they did not cause any trouble under Mageia 1, so I left them. Maybe such links deletion could be added to "mandriva-everytime" service, alongside with temporary files deletion... Thanks for your help anyway. Francois
Yeah I guess systemd will honour the K symlinks differently to sysvinit which is why the change in behaviour now. I have to say tho', I've never seen the negative symlinks there before (and I just doubled checked on a handful of machines) so I wonder where it comes from. Do you use drakservices wrappers much? It shouldn't be anything to do with it, but you never know.... In the longer term (i.e. mga3) sysvinit will not be supported anyway (tho' we will still support these symlinks for triggering legacy services). In an ideal world we wont actually ship any such scripts, but we'll see how realistic that is. With all this in mind, can we close this bug report? @Andy, Nicolas: As you were the initial reporters, can you confirm that things are OK for you too now?
For my part, problem is solved. about the -1 links, yes I used the drakxservices tool, but last time this was on mga1 (now i've upgraded to mga2)
Hello, regarding comment #3, I was not aware of this change of behaviour (until then, I used openvpn since years in systemV mode). I'm using a fresh mga2 install. In /etc/openvpn, I have : -rw-r--r-- 1 root root 3619 juin 13 19:37 photon_1195_client.conf -rwxr-xr-x 1 root root 599 oct. 20 2011 photon_1195_client.up "status" gives this : systemctl status openvpn@photon_1195_client.service openvpn@photon_1195_client.service - OpenVPN Robust And Highly Flexible Tunneling Application On photon_1195_client Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/openvpn@.service/photon_1195_client But then "enable" gives an error : systemctl enable openvpn@photon_1195_client.service Failed to issue method call: No such file or directory Am I missing anything in the steps to enable openvpn ?
(In reply to comment #13) > "status" gives this : > > systemctl status openvpn@photon_1195_client.service > openvpn@photon_1195_client.service - OpenVPN Robust And Highly Flexible > Tunneling Application On photon_1195_client > Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled) > Active: inactive (dead) > CGroup: name=systemd:/system/openvpn@.service/photon_1195_client Cool, that all looks good. > But then "enable" gives an error : > > systemctl enable openvpn@photon_1195_client.service > Failed to issue method call: No such file or directory > > Am I missing anything in the steps to enable openvpn ? Ooops, my bad. I forgot that enabling template units is something that is only in newer systemd releases. I will look to see if we can backport some of the more useful features like this in an update, but for now you have to create the symlinks manually (which is a bit rubbish. As the status output already says it's enabled, you should be OK to go. Can you do "systemctl start openvpn@photon_1195_client.service" and see what happens? If the command takes a long time, just let it run is course. Then let me know what the "status" output is again and if it's not working, the "systemctl show openvpn@photon_1195_client.service" output. If it works when you manually start it, then we can investigate where the actual problem lies :)
"start" didn't work completly. openvpn started and established a connection, but then it failed/exited when running the "up" script : systemctl status openvpn@photon_1195_client.service openvpn@photon_1195_client.service - OpenVPN Robust And Highly Flexible Tunneling Application On photon_1195_client Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled) Active: failed (Result: exit-code) since Thu, 16 Aug 2012 09:55:15 +0200; 14s ago Process: 2197 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=0/SUCCESS) Main PID: 2198 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/openvpn@.service/photon_1195_client Aug 16 09:55:15 muon openvpn[2198]: OPTIONS IMPORT: route options modified Aug 16 09:55:15 muon openvpn[2198]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Aug 16 09:55:15 muon openvpn[2198]: ROUTE default_gateway=82.227.xx.yy Aug 16 09:55:15 muon openvpn[2198]: TUN/TAP device tun0 opened Aug 16 09:55:15 muon openvpn[2198]: TUN/TAP TX queue length set to 100 Aug 16 09:55:15 muon openvpn[2198]: /sbin/ifconfig tun0 10.xx.yy.zz pointopoint 10.21.66.29 mtu 1500 Aug 16 09:55:15 muon openvpn[2198]: ./photon_1195_client.up tun0 1500 1542 10.21.66.30 10.21.66.29 init Aug 16 09:55:15 muon openvpn[2198]: WARNING: External program may not be called unless '--script-security 2' or higher is enabled. Use '--script-security 3 system' for backward compatibility with 2.1_rc8 and earlier. See --help text or man page for detailed info. Aug 16 09:55:15 muon openvpn[2198]: WARNING: Failed running command (--up/--down): external program fork failed Aug 16 09:55:15 muon openvpn[2198]: Exiting But when I do /etc/init.d/openvpn start with SYSTEMCTL_SKIP_REDIRECT=1, openvpn starts correctly. In that I case, I don't have this line : WARNING: External program may not be called unless '--script-security 2' or higher is enabled So, it seems the systemd mode doesn't start with the same privileges ?
Hmm, yeah, it seems there is a bit of a kludge in the sysvinit script that deals with adding the --script-security argument when you do not specify it in your conf file. From reading the man page, all that needs done it seems is to add the line: script-security 2 to your .conf file. This is a feature apparently added in OpenVPN 2.1_rc9. The old initscript worked around this, but in a really ugly way that kept users ignorant of the real and proper fix.
It works with scrip-security, I can do systemctl start and get my vpn. For me , the bug can be closed. While waiting for a backported systemd, could you give the commands to create the symlinks that would be created by "systemctl enable" ?
(In reply to comment #17) > It works with scrip-security, I can do systemctl start and get my vpn. Awesome! Good to know. > For me , the bug can be closed. While waiting for a backported systemd, could > you give the commands to create the symlinks that would be created by > "systemctl enable" ? Yeah, just do: ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/multi-user.target.wants/openvpn@whatever-your-conf-file-is-called.service (in a more generic way: look at the unit file (openvpn@.service) and in the [Install] section there should be a WantedBy= entry - it's very often "multi-user.target" (which is the old runlevel 3). Let's call this $TARGET. The enabling symlink should then go in /etc/systemd/system/${TARGET}.wants/ Longer term there will be other, slightly different semantics, but the principle is the same. The systemctl enable command will be much easier :D HTHs
the ln -s did the trick, openvpn started correctly after a reboot. By the way, there was already this link : lrwxrwxrwx 1 root root 36 juin 3 15:37 openvpn@.service -> /lib/systemd/system/openvpn@.service I think it was created when the openvpn rpm was installed. Is this of any use ?
Closing per comment 17
Status: NEW => RESOLVEDCC: (none) => stormiResolution: (none) => FIXED