Bug 1394512 - tinc does not wait for network to be up
Summary: tinc does not wait for network to be up
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: tinc
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fabian Affolter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-12 20:59 UTC by François Kooman
Modified: 2016-11-12 23:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-12 23:04:58 UTC
Type: Bug


Attachments (Terms of Use)

Description François Kooman 2016-11-12 20:59:00 UTC
Description of problem:

tinc does not wait before starting before the network is actually up, or NM is even started. I enabled both NetworkManager service, and NetworkManager-wait-online, see https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.

This is important for me, because I want to add the tinc tun to a bridge in tinc-up that is brought up by NM, so we have to wait for NM to actually activate the bridge.

If tinc starts before NM is done, br0 does not exist, and the vpn interface cannot be added to the bridge.

Version-Release number of selected component (if applicable):

tinc-1.0.28-1.el7.x86_64

How reproducible:

Always, well, most of the time, 9 out of 10.

Steps to Reproduce:

1. create a tinc configuration and make sure it works, systemctl restart tinc@XXXX works perfectly fine;
2. systemctl enable NetworkManager
   systemctl enable NetworkManager-wait-online
   systemctl enable tinc
   systemctl enable tinc@XXXX
3. reboot

Actual results:

tinc was started before NetworkManager was even started, let alone finished;

Expected results:

systemd should wait for NM to start and configure the interfaces, then only start tinc;

Additional info:

It seems tinc.service depends on network.target, so that should be fine with NetworkManager-wait-online enabled, and it works for most other services as far as I can tell, just not tinc. 

Maybe this is actually a systemd bug, where having services that use a "@" do not work properly? or only on systemd versions >= the one in CentOS 7?

Comment 1 François Kooman 2016-11-12 21:33:17 UTC
I also created a copy of tinc.service in /etc/systemd/system, and changed the "After" to contain network-online.target, and also added the Wants line.

-- cut --
# This is a mostly empty service, but allows commands like stop, start, reload
# to propagate to all tinc@ service instances.

[Unit]
Description=Tinc VPN
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/tinc

[Install]
WantedBy=multi-user.target
-- /cut --

This also doesn't help:

[fkooman@vpn system]$ systemctl -p After show network-online.target
After=network.target network.service NetworkManager-wait-online.service
[fkooman@vpn system]$ systemctl -p Wants show network-online.target
Wants=NetworkManager-wait-online.service
[fkooman@vpn system]$ systemctl show -p Wants tinc
Wants=network-online.target system.slice tinc
[fkooman@vpn system]$ systemctl show -p After tinc
After=basic.target -.mount network-online.target systemd-journald.socket system.slice
[fkooman@vpn system]$ systemctl show -p After tinc@vpn
After=-.mount systemd-journald.socket basic.target system-tinc.slice

Comment 2 François Kooman 2016-11-12 21:38:54 UTC
I fixed it by using the OpenVPN service as a template, works like a charm now:

-- cut --
[Unit]
Description=Tinc net %i
After=network.target

[Service]
Type=simple
WorkingDirectory=/etc/tinc/%i
ExecStart=/usr/sbin/tincd -n %i -D
ExecReload=/usr/sbin/tincd -n %i -kHUP
ExecStop=/usr/sbin/tincd -n %i -k
TimeoutStopSec=5
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target
-- /cut --

Maybe this should become the default file?

Comment 3 François Kooman 2016-11-12 23:04:58 UTC
https://github.com/gsliepen/tinc/issues/133


Note You need to log in before you can comment on or make changes to this bug.