The newly installed server is unstable, and the ATAK connection frequently goes offline.

[7517104]

The newly installed server is unstable, and the ATAK connection frequently goes offline.
system is Ubuntu 22.4
The attachment is the server log.
The logs seem to indicate a problem with RabbitMQ.
opentakserver.log

[Humble-Helper-96]

I dont really know what I am doing but I tossed your log into AI and it spit back the following: (Take it for what it is worth, could be nothing lol)

It looks like there are two separate issues in your logs.

1) RabbitMQ is shutting down / restarting (likely the main cause of ATAK going offline)

Your log shows the AMQP connection being forcibly closed because the broker is shutting down:

• CONNECTION_FORCED - broker forced connection closure with reason 'shutdown'
• RabbitMQ channel closed ...

When RabbitMQ drops, components that depend on it (message handling/queues) will become unstable, which matches “ATAK frequently goes offline”.

Suggested checks:

sudo systemctl status rabbitmq-server --no-pager
sudo journalctl -u rabbitmq-server -n 300 --no-pager -l
df -h
free -h

You’re looking for crash loops, disk alarms/low disk space, OOM kills, port conflicts, etc.

---

2) eud_handler is throwing exceptions because self.user is None

You have repeated stack traces like:

• AttributeError: 'NoneType' object has no attribute 'id' in parse_device_info()

This happens right after “New TCP connection…”, and I also see connections from a public internet IP (e.g. New TCP connection from 182.118.232.30). That strongly suggests you have a port exposed to the internet and are getting scanners / unauthenticated connects, which then hit a code path that assumes an authenticated user.

Strong recommendation:

• Don’t expose EUD handler / TAK ports directly to the public internet.
• Put ATAK access behind VPN (WireGuard/ZeroTier) or firewall-source-limit to your LAN/VPN subnet.

If you’re using UFW, conceptually:

sudo ufw default deny incoming
sudo ufw allow from <LAN_or_VPN_subnet> to any port <your_TAK_ports> proto tcp
sudo ufw enable

(Replace with the actual ports you’re using.)

---

TL;DR

• Fix RabbitMQ stability first (it’s explicitly shutting down in your logs).
• Lock down exposed ports (the public IP connects + self.user None crash path is a red flag).

If you paste the output of:

journalctl -u rabbitmq-server -n 300 --no-pager -l
systemctl status rabbitmq-server --no-pager

…it’ll likely show the exact reason RabbitMQ is shutting down.

[brian7704]

I think this is fixed as of 1.7.9 but I could use some testers to verify. If you're still experiencing this issue please upgrade to 1.7.9 and let me know if the problem persists.

[7517104]

I think this is fixed as of 1.7.9 but I could use some testers to verify. If you're still experiencing this issue please upgrade to 1.7.9 and let me know if the problem persists.

I upgraded to version 1.7.10 and used it for 3 days. During these 3 days, EUD has remained online and I haven't noticed it going offline.