Routing issue? - a python script as a service, isn't connecting to a tailscale IP address

Forums › Linux › Routing issue? - a python script as a service, isn't connecting to a tailscale IP address

ZollyMonsta

3009 posts

Uber Geek
+1 received by user: 379

ID Verified

Trusted

#318037 9-Dec-2024 15:55

Hi there..

I have another curly one.

I have been successful in using a python script to connect between two different raspberry pi's over tailscale.
The same command line, set up to run as a service, fails to connect to the other IP address.

I have also tried setting a route on the tailscale0 device for both IPs on both pi's, but this doesn't resolve the issue.

Running the script manually, no issue at all.

Example Route (it was a stab in the dark if this was the actual problem)

pi@open-ob-remote-belmont:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 enxb827eb14cff3
<tailscale IP of Pi 1> 0.0.0.0 255.255.255.255 UH 0 0 0 tailscale0
<tailscale IP of Pi 2> 0.0.0.0 255.255.255.255 UH 0 0 0 tailscale0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 enxb827eb14cff3

The command itself runs via this in the original file on Pi 2:

sudo openob <ip of pi 1> cheesenode link1 rx -a alsa -d hw;0,0 &

I have to remove & for it as a service. I've tried with and without 'sudo' with no change..

Thanks

Check out my LPFM Radio Station at www.thecheese.co.nz - Now on iHeart Radio, TuneIn and Radio Garden

As per the usual std disclaimer.. "All thoughts typed here are my own."

LennonNZ

2459 posts

Uber Geek
+1 received by user: 411

ID Verified

Trusted

#3318433 9-Dec-2024 16:25

A few things you can try..

nohup rather than &
check logs via journalctl -u <your-service-name>.service
check env variables (use env > /tmp/service_env.log in your script) as these may be different than when running manually

fe31nz

1294 posts

Uber Geek
+1 received by user: 423

#3318601 9-Dec-2024 23:02

When you say running it as a service, do you mean running it from systemd .service unit? Is the service "Type=oneshot"? If so, then you probably need to add

RemainAfterExit=yes

in the [Service] section of the unit file.

I had a problem like this where I was running a python program to retry mounting some sshfs mount points that were late becoming available at boot time. The program was able to mount them when run manually, but when run as a service it reported mounting them, but when I tried to access the mount points they were not mounted. It turned out that systemd starts programs in a separated environment (namespace?) or something similar, and when the service stops, systemd removes everything in that environment automatically, such as mount points and routing table entries. Using RemainAfterExit=yes tells systemd to retain the environment (and so all the changes to the system setup) until the unit gets stopped when the system shuts down (or it otherwise is stopped). Without RemainAfterExit=yes, a oneshot unit gets stopped as soon as the program it runs exits.