Skip to content

Commit

Permalink
Improve [email protected]
Browse files Browse the repository at this point in the history 
Based on equivalent OpenVPN file:
`distro/systemd/[email protected]`

See also OpenVPN service:
https://community.openvpn.net/openvpn/wiki/Systemd
  • Loading branch information
@DimitriPapadopoulos
DimitriPapadopoulos committed May 4, 2023
1 parent 3377077 commit 5c71e1f
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion lib/systemd/system/[email protected]
View file
Original file line number Diff line number Diff line change
@@ -1,12 +1,16 @@
[Unit]
Description=OpenFortiVPN for %I
After=network-online.target
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openfortivpn(1)
Documentation=https://github.com/adrienverge/openfortivpn#readme
Documentation=https://github.com/adrienverge/openfortivpn/wiki

[Service]
Type=notify
PrivateTmp=true
ExecStart=@BINDIR@/openfortivpn -c @SYSCONFDIR@/openfortivpn/%I.conf
Restart=on-failure
OOMScoreAdjust=-100

[Install]
Expand Down

3 comments on commit 5c71e1f

@peterhoeg
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

syslog.target was removed from systemd in 2013.

@DimitriPapadopoulos
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, see:

I presume there should be no harm in keeping it for the time being, but there is also no reason to add it in 2023. I'll remove it.

From the systemd.unit man page:

Wants=

Configures (weak) requirement dependencies on other units. [...]

Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole, and this unit will still be started. This is the recommended way to hook the start-up of one unit to the start-up of another unit.

Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. [...]

Requires=

Similar to Wants=, but declares a stronger requirement dependency. [...]

If this unit gets activated, the units listed will be activated as well. If one of the other units fails to activate, and an ordering dependency After= on the failing unit is set, this unit will not be started. Besides, with or without specifying After=, this unit will be stopped (or restarted) if one of the other units is explicitly stopped (or restarted).

Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Before=, After=

When two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied. I.e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down. [...]

Note that those settings are independent of and orthogonal to the requirement dependencies as configured by Requires=, Wants=, Requisite=, or BindsTo=. It is a common pattern to include a unit name in both the After= and Wants= options, in which case the unit listed will be started before the unit that is configured with these options.

I really don't know what to do. I suggest we keep Wants= and not Requires=. And perhaps we should get rid of After= so that openfortivpn is not stopped when network-online stops. That might not be the case right now, but a VPN connection could survive network small outages or roaming using the session cookie.

@peterhoeg Thoughts?

@peterhoeg
Copy link

@peterhoeg peterhoeg commented on 5c71e1f May 5, 2023 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please sign in to comment.