Index | Thread | Search

From:
Douglas Silva <doug.hs@proton.me>
Subject:
Re: net/syncthing: failed to increase receive buffer size (quic-go)
To:
"ports@openbsd.org" <ports@openbsd.org>
Cc:
"edd@openbsd.org" <edd@openbsd.org>, Klemens Nanni <kn@openbsd.org>
Date:
Mon, 26 Jan 2026 13:24:45 +0000

Download raw body.

Thread
Below are my proposed additions to the README file, assuming we don't want to silence the warning.

I've added a short section on logging too.


Index: pkg/README
===================================================================
RCS file: /cvs/ports/net/syncthing/pkg/README,v
diff -u -p -u -p -r1.9 README
--- pkg/README	1 Jan 2026 22:24:37 -0000	1.9
+++ pkg/README	26 Jan 2026 13:18:14 -0000
@@ -22,8 +22,8 @@ Starting via RC script
 Syncthing can be started via the included RC script, thus running
 Syncthing as a system service. This is fine for single user
 configurations. Under this mode of operation, Syncthing runs as the
-_syncthing user, and the default location for folders is
-${LOCALSTATEDIR}/syncthing.
+_syncthing user (or whatever `syncthing_user` is set to in RC), and
+the default location for folders is ${LOCALSTATEDIR}/syncthing.
 
 Starting Manually
 -----------------
@@ -45,6 +45,16 @@ This will result in a new tmux(1) sessio
 boot. The user can later use `tmux attach` to view and control their
 Syncthing process.
 
+Logging
+=======
+
+By default, logs are not saved anywhere; but you can read the logs
+for the current session on the web GUI.
+
+To log to a file, use `syncthing_flags`. Example:
+
+       syncthing_flags="--log-file /var/log/syncthing/syncthing.log --log-max-old-files 5 --log-max-size 2000000"
+
 File Descriptor Limits
 ======================
 
@@ -87,3 +97,16 @@ Another option is to turn off the file w
 This will result in much reduced file descriptor usage at the cost of a
 (configurable) latency. See "watch for changes" and "full rescan interval" in
 the "advanced" tab in a folder's settings (on the web UI).
+
+UDP Buffer Size
+===============
+
+quic-go requests about 8 MB of UDP buffer space. On some platforms, it is able to increase the limit automatically on startup. On OpenBSD this fails with the following warning:
+
+       2026-01-24 12:33:01 INF failed to increase receive buffer size (wanted: 7168 kiB, got 0 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
+
+We can manually increase it by changing `net.inet.udp.recvspace`. Unfortunately, this limit can only be raised to a maximum of 2097152 (approx. 2 MB). For context, see the discussion at https://github.com/quic-go/quic-go/issues/3476.
+
+       # sysctl net.inet.udp.recvspace=2097152
+
+Add that to sysctl.conf(5) to permanently set it.






On Sunday, January 25th, 2026 at 13:00, Douglas Silva <doug.hs@proton.me> wrote:

> 
> 
> 
> 
> Hi,
> 
> When you start Syncthing, one of the first log entries is this warning:
> 
> 2026-01-24 12:33:01 INF failed to increase receive buffer size (wanted: 7168 kiB, got 0 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
> 
> The linked wiki page explains that quic-go tries to automatically increase the buffer size on some platforms (not BSDs), and it has instructions for manually doing it on others; but the section on BSDs doesn't apply to OpenBSD. There is an open issue [1] about it.
> 
> Someone there has figured out that the sysctl variable to change here is "net.inet.udp.recvspace", but it can only be increased to about 2 MB (2097152) — well below the target 7.5 MB (8441037). I have no idea whether quic-go is able to work properly with this. Either way, the warning persists.
> 
> So, my idea is to:
> 
> 1. Modify our package README with instructions to increase the buffer size to maximum.
> 2. Silence the warning by setting the variable "QUIC_GO_DISABLE_RECEIVE_BUFFER_WARNING" [2] [3]
> 
> What do you think?
> 
> 
> [1] https://github.com/quic-go/quic-go/issues/3476
> [2] https://github.com/quic-go/quic-go/blob/4a8af22606c2d237da39212a734b80026a9a0bb0/sys_conn.go#L59
> [3] https://github.com/quic-go/quic-go/issues/3801#issuecomment-1882365505