openbsd-ports/net/syncthing/pkg
ajacoutot c4096e6659 Stop using the daemon class in @newuser.
If we need to make an exception we can do it and properly document the
reason but by default we should just use the default login class.
rc.d uses daemon or the login class provided in login.conf.d so this has
no impact there.

discussed with sthen@, tb@ and robert@

praying that my grep/sed skills did not break anything and still
believing in portbump :-)
2022-11-08 11:16:56 +00:00
..
DESCR
PLIST
README
syncthing.rc

+-----------------------------------------------------------------------
| Running ${PKGSTEM} on OpenBSD
+-----------------------------------------------------------------------

Compatibility
=============

Please note that not all versions of Syncthing are compatible. The
second number in the release string must match. E.g. 0.12.x is not
compatible with 0.13.x. If you mismatch the versions, hosts will fail to
discover each other.

Starting Syncthing
==================

There are a couple of different ways to invoke Syncthing. Which is best
for you will depend upon how many users will run Syncthing concurrently.

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 will run as the
_syncthing user and store the default 'Sync' folder under
${VARBASE}/syncthing.

Starting Manually
-----------------

The other way is to simply invoke ${TRUEPREFIX}/bin/syncthing manually.
This is a better choice for situations where several users all want to
run their own instances of Syncthing. Under this mode, the default
'Sync' folder will be stored in the user's home directory. Users will
have to configure Syncthing to listen on different TCP ports for this
method to work.

It might be desirable to have Syncthing executed on system reboot for
each user individually. To achieve this a crontab entry can be created
on per-user basis:

@reboot tmux new-session -d '${TRUEPREFIX}/bin/syncthing'

This will result in a new tmux(1) session being spawned each system
boot. The user can later use `tmux attach` to view and control their
Syncthing process.

File Descriptor Limits
======================

Syncthing is fairly hungry for file descriptors and the default limits may be
insufficient. On OpenBSD, Syncthing uses kqueue(2) to "watch" files, and since
kqueue(2) doesn't support recursive watching, each file has be watched
individually. The upshot of this is that each file in a watched folder will use
one file descriptor.

If you run Syncthing via the rc.d(8) script, then you can give
Syncthing more file descriptors by adding the following to login.conf(5):

       syncthing:\
                :openfiles-cur=4096:\
                :openfiles-max=4096:\
                :tc=daemon:

Don't forget to rebuild the login.conf.db file (if necessary):

        # [ -f /etc/login.conf.db ] && cap_mkdb /etc/login.conf

Note that in addition to ulimits, there is a kernel-level file descriptor limit
which may also need to be adjusted. This limit is managed through the
kern.maxfiles sysctl(8).

Another option is to turn off the file watcher and use only periodic scans.
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).