The Case of the Disappearing DDNS

When OwnTracks Goes Silent, But Your Pi is Still Humming

It’s a familiar scenario for many home lab enthusiasts: you’ve got services running sweetly on your Raspberry Pi, accessible from anywhere thanks to Dynamic DNS. For me, that includes an OwnTracks setup, relaying location data via my Pi, which also serves as a trusty Mosquitto MQTT broker.

[embed]Building a Raspberry Pi 5 Family Location Tracker with Node-RED, Mosquitto, and OwnTracks A journey into home automation and real-time location sharing, with a healthy dose of head-scratching and eventual…blog.devgenius.io

This afternoon, I noticed my OwnTracks tracker had gone silent — no updates. Curiously, on my local network, the Raspberry Pi and its Mosquitto broker were humming along just fine. This immediately pointed to a classic problem: my Pi was likely unreachable from the outside world. The prime suspect? A hiccup with my Dynamic DNS.

I use No-IP, and their Dynamic Update Client (DUC) is responsible for ensuring my ever-changing home IP address is correctly mapped to my memorable hostname. If the DUC stops working, services like OwnTracks, which rely on that external connection, are the first to raise a silent alarm. Even more frustratingly, this wasn’t the first time; this gremlin had surfaced before, mysteriously vanishing after about six weeks of perfect operation, only to return.

Here’s a log of the troubleshooting steps I went through this time, the dead ends, the “aha!” moments, and the eventual fix that (fingers crossed!) has banished this issue for good.

Step 1: Is it No-IP’s Fault or My Pi? The DDNS Sanity Check

Before diving deep into the Pi’s configuration, the first sanity check was to see if the No-IP service itself was okay or if my account had issues. I logged into the No-IP website and manually updated my hostname to my current public IP address. Result: Success! The manual update worked. This was a crucial piece of information: the problem lay somewhere on my Raspberry Pi with the DUC software, not with No-IP’s service or my account. The OwnTracks silence was indeed a symptom of my DUC not doing its job.

Step 2: The DUC Detective Work — Is noip2 Even Running?

The No-IP DUC on Linux is a little program called noip2. My first check on the Pi was its status:

sudo noip2 -S

The output was rather telling:

No noip2 processes active.
Configuration data from /usr/local/etc/no-ip2.conf.
Account [myaccount] configured for:
host myhost.ddnskey.com
Updating every 30 minutes via /dev/eth0 with NAT enabled.

(This output is based on one of my actual checks during the process.) Okay, so the configuration was there, but the DUC simply wasn’t running. That explained why updates weren’t happening and why OwnTracks couldn’t phone home!

Step 3: The Mystery of the Missing Auto-Start

If noip2 wasn't running, it meant it hadn't started on boot, or it had crashed. Since it "was working until now," it must have had an auto-start mechanism previously. Time to investigate:

Systemd Service?

This is the modern way to manage services on Linux.

ls -l /etc/systemd/system/noip2.service 
ls -l /lib/systemd/system/noip2.service

Both reported: No such file or directory. So, no systemd service named noip2.service.

Cron Job?

Maybe a scheduled task was kicking it off.

For root: sudo crontab -l reported no crontab for root.

For my user: crontab -l also showed nothing relevant.

**/etc/rc.local?**

The old-school startup script.

cat /etc/rc.local

This gave me: cat: /etc/rc.local: No such file or directory.

This was puzzling. All the common auto-start locations were empty. How had it been working before? And why did it stop, twice, after about six weeks?

Interlude: The Recurring Gremlin & Why?

The “six-week” pattern was odd. Could it be:

• System Updates? Perhaps an OS update was removing or disabling a non-standard startup script.
• SD Card Issues? Unlikely to be so specific, but always a background thought with Pis.
• No-IP Account Quirks? Free No-IP accounts need hostname confirmation every 30 days. While this shouldn’t affect the DUC software on the Pi, if the hostname became inactive, perhaps my attempts to “fix” things locally inadvertently removed the startup mechanism.
• A Fragile Previous Setup? Since I couldn’t find it, maybe the original auto-start was non-standard and easily broken.

At this point, instead of hunting for a ghost configuration, I decided the best path was to implement a new, robust auto-start method.

Step 4: A Fresh Start — Implementing a Robust Systemd Service

Since noip2 worked when started manually (a quick sudo noip2 followed by sudo noip2 -S confirmed it became active), systemd was the way to go.

• Created the service file: sudo nano /etc/systemd/system/noip2.service
• Pasted the configuration:

[Unit]
Description=No-IP Dynamic Update Client
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStart=/usr/local/bin/noip2
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Saved the file, then reloaded systemd and enabled the service:

sudo systemctl daemon-reload
sudo systemctl enable noip2.service

This created the symlink successfully, indicating the service was recognised and set to start on boot.

Step 5: The Plot Twist — Systemd Says “No!” (start-limit-hit)

Eagerly, I tried to start and check the status:

sudo systemctl start noip2.service
sudo systemctl status noip2.service

And was met with an unwelcome sight: Active: failed (Result: start-limit-hit). The service was enabled but failed because noip2 kept exiting too quickly. The line Process: ... ExecStart=/usr/local/bin/noip2 (code=exited, status=0/SUCCESS) was confusing – it exited successfully, but the service failed? For Type=forking, this means the initial process exited (as it should after forking its daemon child), but the child daemon wasn't staying alive.

I briefly considered an alternative:

Can I not just manually make the DUC run once every 30 minutes with crontab?

While tempting, noip2 is designed as a daemon. Running it repeatedly via cron without a specific "run-once" flag (which I wasn't sure it had) could lead to multiple instances or errors. Debugging the systemd approach felt like the more robust solution.

Step 6: The Breakthrough — Clearing the Decks

The start-limit-hit often means something is preventing the daemon from initializing correctly or staying up. My previous manual start of noip2 might be interfering. noip2 usually creates a PID file to prevent multiple instances.

Killed any lingering noip2 process:

sudo noip2 -K PID # Kills all noip2 instances replace PID with your actual process id
sudo noip2 -S # Confirmed: No noip2 processes active

Reset systemd’s failed state for the service:

sudo systemctl reset-failed noip2.service

Tried starting it again via systemd:

sudo systemctl start noip2.service

Crucially, checked the detailed journalctl logs immediately:

sudo journalctl -u noip2.service -n 50 --no-pager --since "5 minutes ago"

Step 7: Victory! Green Lights and Happy Logs

The journalctl output was the key to confirming success:

May 06 21:58:28 my-pi systemd[1]: Starting noip2.service - No-IP Dynamic Update Client...
May 06 21:58:28 my-pi noip2[1106]: v2.1.9 daemon started with NAT enabled
May 06 21:58:28 my-pi systemd[1]: Started noip2.service - No-IP Dynamic Update Client.
May 06 21:58:29 my-pi noip2[1106]: group[all] was already set to [CORRECT IP ADDRESS].

(Actual log times and PIDs from my session showed here.) Success! The noip2 daemon started, confirmed by its own log message, and systemd reported the service as successfully started. The final noip2 log even helpfully noted my IP hadn't changed, so no immediate update was needed.

A final sudo systemctl status noip2.service confirmed it was active (running). My OwnTracks should be back in business!

Key Takeaways

• Specific Symptoms are Key: Noticing a dependent service (like OwnTracks) failing can be the first clue to a DDNS issue, even if the Pi itself is fine locally.
• Isolate the Problem: The manual No-IP website update quickly told me the issue was local to my Pi.
• Check the Process: sudo noip2 -S is vital for seeing if the DUC is actually running.
• Systemd is Your Friend (Usually): For auto-starting services, systemd is robust. If a service file is missing, creating one is often the best fix.
• **start-limit-hit in Systemd:** This often means the service is exiting too quickly. For forking daemons, ensure any manually started instances are killed, as they can interfere (e.g., via PID files).
• **journalctl is Your Superpower:** systemctl status gives an overview, but journalctl -u your-service-name.service provides the detailed logs from the service itself, which are crucial for debugging.
• Recurring Issues: If a problem recurs, especially after a fixed interval, consider external factors like system updates or account maintenance cycles that might indirectly lead to manual misconfiguration during “fixes.” A robust systemd setup should minimize issues related to the startup mechanism itself.

Hopefully, with a proper systemd service now in place, this DDNS gremlin has been banished for good.

If you’ve faced similar issues getting your Raspberry Pi to reliably update No-IP, I hope this detailed walkthrough helps you on your own troubleshooting quest!