Landscape SaaS Appears to be broken

We’re on AWS and slowly switching our Linux instances over to Ubuntu 24.04 and Unbutu Pro with Landscape to centrally manage them. Things were working fine on the first few servers for months. However it’s appeared that Landscape and the agent aren’t properly communicating.

I had a server that had 2 pending updates - applied the updates immediately, and the task just sits there, upgrade in progress for 3 hours, never completed.

I had one server pending reboot, told it to reboot and it sat there pending for 12 hours - never completed.

I attempt to run a super basic test script “ps -aux”, it sits there in progress indefinitely. Verified on the client that the script actually did run successfully with data waiting to be shipped up to Landscape, but it just sits there.

Feels like no notifications are able to get to Landscape so nothing is getting updated. Before I’d get an occasional message that the client wasn’t reporting, but it would fix itself very quickly.

What could possibly be happening and why was it good for so long and now completely broken.

AI Summary:

Since **2026-05-25**, every Ubuntu **24.04 (noble)** machine in our account stopped reliably

reporting package data to hosted Landscape. The Landscape web UI shows **"computer has not

reported package information,"** package-related activities (e.g. “upgrade these packages”) sit

in *Running*/*Queued* for hours despite the change completing on the host, and package resyncs

take multiple hours. The machines remain **online (pings are current)** the whole time, which

masks the problem.

The package-reporter log on **every** affected host repeatedly logs:

```

WARNING [MainThread] Removing cached hash=>id database \

/var/lib/landscape/client/package/hash-id/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_noble_amd64

```

(`_noble_arm64` on Graviton hosts.) The client then falls back to per-package

`hash => id` translation in small batches (5–500 at a time), which never converges because

ESM/Pro is enabled and the apt universe is ~97,000 package versions. The broker exchange

reports **`Pending messages remain after the last exchange`** on essentially every cycle and

never drains.

1. **Two unrelated hosts, two different CPU architectures, began the identical failure on the

same calendar day.** First `Removing cached hash=>id database` entry:

- Host A (arm64, `_noble_arm64`): **2026-05-25 13:08**

- Host B (amd64, `_noble_amd64`): **2026-05-25 19:19**

These machines have different workloads and patch schedules; the only thing they share is the

hosted Landscape server. Independent clients do not coordinate a failure to the same day by

chance.

2. **The `landscape-client` package has not changed since February 2026** (dpkg install date,

and Installed == Candidate == `24.02-0ubuntu5.7`). No client upgrade correlates with onset.

3. **Brand-new hosts are affected too.** Two hosts first registered on 2026-06-22 each logged

their first `Removing cached hash=>id database` within hours of registration — so this is not

accumulated local state corruption; a freshly-registered client hits it immediately.

4. **Rebooting an affected client changed nothing** — package reporting remained broken after a full reboot, consistent with a server-side condition.

5. The discarded database is the **archive hash-id DB the server provides**

(`af6f2dcf-1967-11de-8dd0-001a4b4d8d10_noble_`), not local config.

Thanks for the detailed report. Could you file this issue at https://bugs.launchpad.net/landscape? That’s the canonical place for Landscape bugs, and it’ll make it much easier to track, attach logs, prioritize and keep updates in one place.

1 Like

Thanks - report submitted. I added some more data points to the bug report as well. There’s definitely a significant delay between communication from Landscape → Client/Execution (fast) vs Client → Landscape data return (horribly slow).

https://bugs.launchpad.net/landscape/+bug/2158144