Tailscale Autostart on Raspberry Pi

I am on Raspbian Buster running Tailscale 1.8.5 with the following command, and it works well.

sudo tailscale up --advertise-routes=192.168.2.0/24,192.168.20.0/24 --advertise-exit-node

However, it used to be that Tailscale would automatically start with all those options upon reboot or power up with no intervention.

But now every time I reboot and run:

tailscale status

It returns:

Tailscale is stopped.

Which means I have to manually run the long command.

How can I get Tailscale to run that command on a reboot? I thought “Unattended Server Mode” was on by default (not sure if that is what it is called).

Thanks,

Chris

Hello Chris,

by default, tailscaled service should start on boot on Raspbian Buster.
If it doesn’t happen in your case you, should check if it wasn’t failed on start:

sudo systemctl --failed

If you see tailscaled in the list you can check logs for why it wasn’t able to start normally:

journalctl -u tailscaled

Running sudo systemctl --failed returns 0 loaded units listed.

While I was waiting for this post to be approved, I did reach out to support and they had me run:

journalctl -u tailscaled | grep "backend prefs for" which returns

tailscaled[516]: backend prefs for "_daemon": Prefs{ra=false dns=true want=false routes=[0.0.0.0/0 ::/0 192.168.2.0/24 192.168.20.0/24] snat=true nf=on Persist{lm=, o=, n=[38Vma] u="myemaily@gmail.com"}}

They say that want=false is the problem, and is likely something going wrong when saving the /var/lib/tailscale/tailscaled.state file.

Support suggests it might be a filesystem options issue with the microSD card, but offer no suggestions on how to check that or address it.

I have 2 Raspberry Pis with different microSD cards, and I really don’t think it is a filesystem issue with the microSD card, since the problem is on both Pis and even though one is a fresh install, the other has had Tailscale on it for a long times, and both exhibit the issue.

Autostart used to work back in the Tailscale (1.5?) days, so I feel like perhaps something changed with Tailscale itself or something happened as part of the normal apt update/upgrade.

Just to be clear, I have vanilla Buster installs using Balenaetcher on macOS to the microSD card, followed by a fairly vanilla Pi-Hole install, and then Tailscale install. Support says they followed this process on their own Pi and had no issues with Tailscale starting on reboot.

Bumping in hopes someone might have run into the same issue, or perhaps a bug can be raised.

Is tailscaled.service in /etc/systemd/system/multi-user.target.wants? Do you have some process that clears out /etc to defaults on boot?

Try systemctl enable --now tailscaled.service and see if that helps?

I do not have any process I am aware of that clears out /etc.

Pretty vanilla install of Buster, Pi-Hole, and then Tailscale.

tailscaled.service was in /etc/systemd/system/multi-user.target.wants

Running systemctl enable --now tailscaled.service didn’t seem to help. Upon reboot, Tailscale still shows as stopped even though it was running just before rebooting.

Which raspbian variant are you using?

cao-2000: we’ve already spent substantial time trying to reproduce the issue you’re reporting, on two different Raspberry Pi devices. We just don’t see this issue.

If you believe that older releases worked for you then you’re welcome to keep using those:
https://pkgs.tailscale.com/stable/raspbian/pool/tailscale_1.4.5_armhf.deb
or
https://pkgs.tailscale.com/stable/raspbian/pool/tailscale_1.4.5_arm64.deb

I appreciate very much the time you have taken to try to reproduce.

You suggested it might be a filesystem options issue with the microSD card, but offered no suggestions on how to check that or address it.

So my hope was that someone from the community had run into something similar.

And although I could use a very old version, that would mean missing out on features like Exit Nodes, and more.

I am on Raspbian 10 (Buster).

Another thread, a poster had a similar issue.

Turns out running the full tailscale up command with --force-reauth seems to have done the trick.