The ways to start Direwolf at boot, as provided in the manual, are quite archaic and hacky. Let’s see how we can do this in a more modern way using systemd.
Why I don’t like the solution provided in the manual
In the paragraph “5.9 Automatic Start Up After Reboot” the direwolf manual suggests using /etc/rc.local to start direwolf on boot. rc.local is an ancient way to do stuff on boot. However it has several drawbacks:
- You are not sure when it is called i.e. if all the system resources you need are already available
- AFAIK it has been deprecated since debian 9 (yet it is still working if you create it manually)
- No way to restart direwolf automatically if, for whatever reason, it fails
To address the latter problem the manual suggests to configure (dw-start.sh) a shell script as a cron job. Executing the script every minute. This will force direwolf to restart endlessly by banging the shell script every minute! But what if for some reason I really want to stop direwolf for a while? It’s impossible as the script will restart it right away… Not good…
Why it is better to do it using systemd?
- Start and stop direwolf whenever I want
- I can add other services which rely on direwolf and have them started after direwolf
- Automatically restart direwolf when it fails
- It is the way of doing such things on a modern Linux distro
Doing it the SystemD way
Using direwolf directly as a systemd (Type=simple) resulted in a strange effect: the service was never going out of the start phase, thus i decided to rely on tmux. Using tmux also brings the ability to observe what direwolf is doing at any moment, even with the fancy colored output!
Install tmux
sudo apt install tmuxCode language: Bash (bash)Now we can create our systemd unit: create the following file /etc/systemd/system/direwolf.service
You have to adapt the command line to fit your own needs i.e. path to your config file
[Unit]
Description=Direwolf
After=network.target
[Service]
Type=forking
#Modify the end of the line below to fit your own needs i.e path to your configuration file
ExecStart=/usr/bin/tmux new-session -d -s direwolf '/usr/local/bin/direwolf -c /home/pi/direwolf.conf'
Restart=always
[Install]
WantedBy=default.target
Code language: Makefile (makefile)Next step enable the service
sudo systemctl enable direwolf.serviceCode language: Bash (bash)If everything went OK you can now start the service using
sudo systemctl start direwolf.serviceCode language: Bash (bash)To stop it
sudo systemctl stop direwolf.serviceCode language: Bash (bash)Request its status
sudo systemctl status direwolf.serviceCode language: CSS (css)To attach to the tmux terminal in order to watch direwolf do its thing
sudo tmux attach -t direwolfConclusion
That’s it! We have direwolf running as a systemd service. There are a couple of things that could be improved though, but I leave them for later as I am so far happy wiht how it is working.
- Do not run as root user
- Templated systemd unit in order to specify the config file.
This has been very helpful. I do have one recommendation based upon my experience with GPSD beacons when GPSD is using location over the network.
Apparently direwolf will only “connect” to the GPSD server one time and if the network is taking time to finish going online, the connection attempt will fail. igate connection will also fail but the igate connection will be retried after a few minutes.
I changed the After line to the following:
After=network-online.target
This has the only downside that it will sit in startup forever if the network does not go online.
Hi Joe,
Thank you for our comment.
This is funny because I also just started playing around with GPSD and Direwolf. I am using latest direwolf from the dev branch, which version are you using?
I am under the impression that it will try at start to connect to GPSD and if it succeed it will retry if for whatever reason the connection drops.
Currently putting up a direwolf based tracker together, it will never reach online target when in the car and came to the same conclusion than you.
I ended up adding these line to the unit file, but wanted to give it further tests before updating the article.
Requires=gpsd.service,gpsd.socketThis will eventually lead to add a strong dependency between both service, if GPS fails to start, direwolf will not start either. If gpsd is not started, systemd will start it before starting direwolf.
Pingback: My APRS IGate VK2MES-5 and a Flowerpot High Gain antenna – Zindello's Ramblings
Have just borrowed your exact setup here to get direwolf starting on boot in Centos 8. For some reason it thinks it’s being started as root although I specified to start as a new “direwolf” user so I need to investigate that. Maybe I stuffed up a group somewhere?
Anyway thanks for posting. Made my evening a little bit easier.
Hi Josh,
Thanks for your comment and feedback, I am glad the post helped you in some way.
What do you mean with “I specified to start as a new “direwolf user” ? Did you create the direwolf userbefore? did you specify user and group in the unit file?
Systemd will start tmux with the user specified in the unit file and in turn tmux will start direwolf using that same user.
BTW Does it actually start as root ?