It appears that systemd has sensible defaults for limiting
crash loops:
DefaultStartLimitIntervalSec=10s
DefaultStartLimitBurst=5
Remove our insta-restart configuration so that it works.
Signed-off-by: David Crawshaw <crawshaw@tailscale.com>
So a backend in server-an-error state (as used by Windows) can try to
create a new Engine again each time somebody re-connects, relaunching
the GUI app.
(The proper fix is actually fixing Windows issues, but this makes things better
in the short term)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
- Reformat the warning about a message being rate limited to print the
format string, rather than the formatted message. This helps give a
clue what "type" of message is being limited.
- Change the rate limit warning to be [RATE LIMITED] in all caps. This
uses less space on each line, plus is more noticeable.
- In tailscaled, change the frequency to be less often (once every 5
seconds per format string) but to allow bursts of up to 5 messages.
This greatly reduces the number of messages that are rate limited
during startup, but allows us to tighten the limit even further during
normal runtime.
Signed-off-by: Avery Pennarun <apenwarr@tailscale.com>
This cuts RSS from ~30MB to ~20MB on my machine, after the previous fix
to get rid of unnecessary zstd buffers.
Signed-off-by: Avery Pennarun <apenwarr@tailscale.com>
Also stop logging data sent/received from nodes we're not connected to (ie all those `x`s being logged in the `peers: ` line)
Signed-off-by: Wendi <wendi.yu@yahoo.ca>
Implement rate limiting on log messages
Addresses issue #317, where logs can get spammed with the same message
nonstop. Created a rate limiting closure on logging functions, which
limits the number of messages being logged per second based on format
string. To keep memory usage as constant as possible, the previous cache
purging at periodic time intervals has been replaced by an LRU that
discards the oldest string when the capacity of the cache is reached.
Signed-off-by: Wendi Yu <wendi.yu@yahoo.ca>
The device name "tailscale0" will be used for all platforms except for
OpenBSD where "tun" is enforced by the kernel. `CreateTUN()` in
`wireguard-go` will select the next available "tunX" device name on the
OpenBSD system.
Signed-off-by: Martin Baillie <martin@baillie.email>
The autoselection should pick sensible paths for all of:
- Windows (LocalAppData)
- Mac (Library/Caches)
- Unix user (XDG_CACHE_DIR)
- Linux systemd service (CACHE_DIRECTORY)
As a last resort, if cache dir lookup fails, plops sufficiently
uniquely named files into the current working directory.
Signed-off-by: David Anderson <dave@natulte.net>
Port number has to be by itself for substitution to work.
Disabling the restart rate-limiting has to be in [Unit] not
[Service].
Signed-off-by: David Anderson <dave@natulte.net>
On unix, we want to provide a full path to the desired unix socket.
On windows, currently we want to provide a TCP port, but someday
we'll also provide a "path-ish" object for a named pipe.
For now, simplify the API down to exactly a path and a TCP port.
Signed-off-by: David Anderson <dave@natulte.net>
With this change, tailscaled can be restarted and reconnect
without interaction from `tailscale`, and `tailscale` is merely
there to provide login assistance and adjust preferences.
Signed-off-by: David Anderson <dave@natulte.net>
* make RouterGen return an error, not take both tunname and tundev
* also remove RouteGen taking a wireguard/device.Device; currently unused
* remove derp parameter (it'll work differently)
* unexport NewUserspaceRouter in per-OS impls, add documented wrapper
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
It was previously used by the MacOS client, but it now does
something different. ipnserver should never obey a client's
request to exit.
Signed-off-by: David Anderson <dave@natulte.net>
The store is passed-in by callers of NewLocalBackend and
ipnserver.Run, but currently all callers are hardcoded to
an in-memory store. The store is unused.
Signed-Off-By: David Anderson <dave@natulte.net>
OpenBSD tunnel names are prefixed with `tun`.
Controlling the port allows for deterministic configuration of firewall
rules (using `pf` in this case).
Signed-off-by: Martin Baillie <martin@baillie.email>
