When running Ubuntu servers, on reboot services like Postgres and Redis start up before Tailscale and so don’t bind to the mesh IP. How can I modify the Tailscale service to boot before services which need to bind to the mesh IP?
1 Like
you can use systemctl edit to change the parameters for postresql and redis to make them require that tailscaled is already running.
You should do some reading on systemd services, because this may have unintended consequences.
I don’t think editing the configuration of every service requiring network is the right approach.
Isn’t it the case that Tailscale should always start after network and before any other services which require network? I’d also like to have sshd only listen on Tailscale’s IP but ( and I haven’t tested sshd ) I assume it wouldn’t bind to the tailscale IP on reboot.
I would argue that at the very least, services which depend on another service should indicate that dependency in their configuration.
I would argue that tailscale provides network and should boot before services which require network.
How do you all run servers with tailscale? Are you manually modifying the systemd parameters of every service which needs network? I feel like I must be missing something obvious.
The systemd configuration we suggest is stored here: https://github.com/tailscale/tailscale/blob/main/cmd/tailscaled/tailscaled.service
So by default, Tailscale will come up as part of network initialization (i.e. anything that waits for the network will wait for Tailscale), but after NetworkManager & resolvd if they are installed.
One thing maybe worth trying would be putting an After=network-online.target stanza in your Postgres / Redis service config?
2 Likes
In part this depends on the exact semantics that you want, systemd provides a number of options. In this case we’re focusing on two dependency axes, though there are others:
- Wants dependencies: a wants dependency is “weak”, so if the dependency fails, the dependent continues to start
- Requires dependencies: a requires dependency is “hard”, so if the dependency fails, so does the dependent.
You do not need to modify units configurations in order to add dependencies, you can use the CLI and it will add symlinks as described here. e.g.
systemctl add-wants postgresql tailscaled
# or
systemctl add-requires postgresql tailscaled
If you add a Wants dependency, then if tailscaled fails to start, postgresql will start anyway. This maintains availability, but given the original problem description it may or may not be the desired outcome.
If you add a Requires dependency, then if tailscaled fails to start, postgresql will not start. This reduces availability - postgresql will only start if tailscaled is running.
You could also modify the dependencies of the network-online target, however doing so can have additional consequences for other software on the system that are unique to your distribution and configuration so you should make sure you understand what units depend on network-online.target before you do that.
2 Likes