From ArchWiki
Jump to: navigation, search

systemd-networkd-wait-online.service needed?

wq-quick@.service already contains Enabling the wait online service causes the whole boot process to pause while waiting for a network connection and can dramatically increase boot times. —This unsigned comment is by Smasher816 (talk) 03:54, 3 May 2018‎ (UTC). Please sign your posts with ~~~~!

I suspect the long network wait times might be caused by a lack of entropy rather than the target unit. Recommend rng-tools or haveged. Graysky (talk) 12:09, 17 November 2018 (UTC)
systemd-networkd has a timeout of 2 minutes for systemd-networkd-wait-online. See this GitHub issue: (especially this comment). I've had to explicitly tell systemd-networkd to ignore all links on one of my systems (with RequireForOnline=no), because it seems to wait for all devices to be online, not one of them. Aude (talk) 17:40, 17 November 2018 (UTC)
Just a guess based on some delays with a headless box. For some other use cases (wpa_supplicant on a raspberry pi), I needed to use an override as well. Graysky (talk) 19:33, 17 November 2018 (UTC).
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --ignore eth0
Yeah, that makes sense. I did an error and made the reply to your comment Graysky, but it was supposed to be a reply to the original poster. Sorry for the confusion. Aude (talk) 22:05, 17 November 2018 (UTC)

DNS troubleshoot

Until a proper NM plugin is released, weird interactions are going to occur between Wireguard and NM. Typically, if you create a tunnel and NM touches DNS for whatever reason (lease timeout, reconnection, etc.) I loose my connection.

I specifically focused on systemd-resolved because I find the approach much saner than the resolvconf mess. It is also supported by NM and not really "broadly" documented elsewhere. —This unsigned comment is by Gdonval (talk) 10:52, 15 September 2018‎ (UTC). Please sign your posts with ~~~~!

Move `Endpoint with changing IP` to `Tips & Tricks`

I can't justify it being under `Raw usage` as it's only a problem if you reference the server with a domain. I think it can be moved to the tips and tricks section. Foxboron (talk) 13:13, 16 December 2018 (UTC)

No objections. Graysky (talk) 14:07, 16 December 2018 (UTC)
Hey, thank you for your feedback. When I contributed this section I was unsure where I should put it, but I figured its critical enough to include it under the "Usage" section. Why can't you justify this being under "Usage", I think "server with a domain" is a pretty trivial configuration? systemd-networkd examples aren't exactly "Raw usage" either. Also I have just noted that VPN-Server Wireguard#Client_config has exactly the described issue my section covers. Note: I'm happy to move it to "Tips & Tricks", I'm just fairly new to archwiki and I'm trying to get a better understanding of common practices here. -- Insecuriy (talk) 15:12, 16 December 2018 (UTC)
The configuration describes a configuration and/or decision choice. Not something that is inherent to the configuration of wireguard. Arguably not even a common problem. If it was a "trivial configuration" the section wouldn't be needed. The systemd and config parts are examples and not explained with a lot of text and thus fits quite nicely within the "Usage" section. "Tips and tricks" also fits better for opinionated solutions or configurations tips.
Foxboron (talk) 15:19, 16 December 2018 (UTC)
I think this is a common problem, judging by seeing that "even this page" got it wrong under the "VPN Server Client Confing", maybe its a better fit under "VPN Server"? -- Insecuriy (talk) 15:26, 16 December 2018 (UTC)
It is a possible problem for both sections. Listing it under "VPN Server" would not really illustrate that very well. The usage section should be concise and to the point. Trying to fit every problem into that section would not really work in the long run.
Foxboron (talk) 15:31, 16 December 2018 (UTC)