Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#41735 - [openvpn] avoid forking off

Attached to Project: Arch Linux
Opened by Silvio Knizek (killermoehre) - Thursday, 28 August 2014, 09:22 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 13 September 2014, 14:19 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Right now openvpn is forking off with systemd, which should be avoided. Therefor I propose following .service-file:

### /usr/lib/systemd/system/openvpn@.service ###
[Unit]
Description=OpenVPN connection to %i

[Service]
ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config /etc/openvpn/%i.conf --syslog openvpn@%i --writepid /run/openvpn@%i.pid
PIDFile=/run/openvpn@%i.pid

[Install]
WantedBy=multi-user.target
### end file ###
This task depends upon

Closed by  Dave Reisner (falconindy)
Saturday, 13 September 2014, 14:19 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Type=forking is correct for a service which might need to be ordered against other services. No need to go OMGOPTIMIZED here.
Comment by Jan de Groot (JGC) - Thursday, 28 August 2014, 09:50 GMT
What's the use of a PIDFile when not forking?
Comment by Silvio Knizek (killermoehre) - Thursday, 28 August 2014, 09:51 GMT
@Jan de Groot
According to https://bugs.archlinux.org/task/37059#comment114649 it's just a convinience setting.
Comment by Dave Reisner (falconindy) - Thursday, 28 August 2014, 12:27 GMT
Jan's point is that PIDFile= is ignored in a service which is Type=simple. Writing out a PIDFile for such a service also makes no sense -- you didn't fork and daemonize, therefore you couldn't possibly have lost track of the process (which is the goal of PID files).

Oddly, you ignore my followup which gives a more robust solution for determining whether or not openvpn is still alive.
Comment by Dave Reisner (falconindy) - Thursday, 28 August 2014, 20:03 GMT
This feature request also ignores the idea that some other unit might want to be ordered correctly against openvpn. If we changed this to Type=simple, we'd lose the ability to do this.

So really, I have to ask -- why do you think this "should be avoided"?
Comment by Yamakaky (Yamakaky) - Thursday, 11 September 2014, 07:30 GMT
@Dave : are we sure that the events 'openvpn fork' and 'openvpn ready' are synced ?

The PidFile directive and the --write-pid directives can be removed as it is only for the init system.

A better Service would use a socket unit. It would solve Dave's problem.
Comment by Dave Reisner (falconindy) - Saturday, 13 September 2014, 14:19 GMT
> @Dave : are we sure that the events 'openvpn fork' and 'openvpn ready' are synced ?
No, I'm not, but I'm sure that intentionally increasing the timeframe between these two events is only going to produce more bug reports.

> The PidFile directive and the --write-pid directives can be removed as it is only for the init system.
With a cost and little benefit, as I've already explained.

> A better Service would use a socket unit. It would solve Dave's problem.
...but openvpn has no ingress socket which could be used to activate openvpn.

Loading...