Network UPS Tools / Troubleshooting
NUT Reports Data Stale for a USB UPS
Confirm the current stale response, then separate driver freshness, USB visibility, access and transport evidence without changing shutdown protection.
UPS hardware supplies the driver, the driver supplies upsd, and clients read the server's data. DATA-STALE means the connected driver is not delivering regular updates or has marked them stale; it does not uniquely identify a cable, permission or hardware fault.[3]
Stable manuals support the operational checks here. The separately labelled development protocol document is used only for compatible error semantics, not development CLI options.[1][2][3]
Applicability
- Products
- Network UPS Tools
- Scope
- For Linux with stable NUT 2.8.5, a previously working local USB UPS supported by usbhid-ups, and a current local query that reaches the intended upsd but reports stale data. Excludes remote-server connection failures, other drivers, unsupported hardware, appliance-specific wrappers and shutdown configuration. Identify the exact model and installed package before interpreting its logs.[1][2]
- Last verified
Symptoms
Quick diagnosis
Gather current evidence before choosing a branch. Unknown observations do not establish a failed component.
Read current data from the intended server
Run locally with authorized access. Replace <upsname> with the configured UPS name; localhost must be the intended upsd. This example assumes its default local listener. If the installation uses another listener/port, use its documented query target rather than changing the server.[5][4]
upsc <upsname>@localhost ups.statusRecord version, model and driver
Use existing package/configuration records to identify NUT, the UPS model and its driver. This page does not start a second driver instance or test UPS power state.[1][6]
Keep monitoring protection in place
If current power conditions are uncertain, involve the responsible operator before any intervention. Reading data does not test automatic shutdown or prove the UPS battery is healthy.[7]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceIs this the supported local USB UPS installation?
Confirm Linux, stable 2.8.5, a previously working supported usbhid-ups model and the intended local server.[1][6]
Read the complete diagnostic tree without using the controls
- Is this the supported local USB UPS installation?
Confirm Linux, stable 2.8.5, a previously working supported usbhid-ups model and the intended local server.[1][6]
- Yes, the installation is identified → What does the current local query return?
- No, or applicability is unknown → Investigate the actual error or installation
- What does the current local query return?
Use the intended UPS/server. Do not classify an old warning as the current response.[5][3]
- Data stale from reachable upsd → Do current logs still describe the same freshness problem?
- Current data is available → Current data has recovered
- Different error or server unreachable → Investigate the actual error or installation
- Do current logs still describe the same freshness problem?
Correlate timestamps and driver connection evidence. Do not start a duplicate driver to inspect it.[2]
- Yes, same current stale condition → Is the expected USB UPS visible to the OS?
- Driver disconnected or error changed → Investigate the actual error or installation
- Driver evidence is unavailable → Collect a driver-freshness evidence packet
- Is the expected USB UPS visible to the OS?
Use model/device identity, not a guessed serial pathname.[6]
- Yes, the expected UPS is visible → Is there actual access or competing-driver evidence?
- No, the expected device is absent → Hand off missing USB visibility
- Visibility is unknown → Collect a driver-freshness evidence packet
- Is there actual access or competing-driver evidence?
Distinguish a logged denial or duplicate owner from a theory based only on staleness.[2][6]
- Yes, access or ownership conflict is evidenced → Request access and driver-ownership review
- No such conflict is established → Are driver transport failures repeating?
- Access evidence is unavailable → Collect a driver-freshness evidence packet
- Are driver transport failures repeating?
Correlate the messages with this model and current timestamps.[6]
- Yes, repeated communication errors → Request model-specific transport investigation
- No repeated transport evidence → Is there an exact documented model-specific timing match?
- The evidence is insufficient → Collect a driver-freshness evidence packet
- Is there an exact documented model-specific timing match?
A generic stale warning is not a timing diagnosis.[6][4]
- Yes, model and pattern match documentation → Request a bounded timing assessment
- No exact match or still uncertain → Collect a driver-freshness evidence packet
- Investigate the actual error or installation
Record the precise response and environment. Server reachability, identity, authentication and DRIVER-NOT-CONNECTED need their own investigation.[3]
- Current data has recovered
Retain timestamps and observe recurrence with the owner. Do not claim that a successful query tests battery health or shutdown behavior.[5][7]
- Hand off missing USB visibility
Provide expected identity and current hardware evidence to the operator; no generic unplug or reset test.[6]
- Request access and driver-ownership review
Provide the actual denial or duplicate instance evidence. Any intervention must meet the monitoring-safety boundary below.[2][7]
- Request model-specific transport investigation
Supply current query and repeated driver messages. Communication evidence does not uniquely identify a defective cable or UPS.[6]
- Request a bounded timing assessment
Include the exact model note and observation. Do not tune freshness or shutdown thresholds from this result.[4][6]
- Collect a driver-freshness evidence packet
Keep the exact query, server identity, version, model and time-correlated logs. Ask the operator for missing evidence without disabling protection.[2][5]
Detailed diagnosis
1. Classify the actual response
A reached server reporting DATA-STALE is distinct from DRIVER-NOT-CONNECTED, UNKNOWN-UPS, ACCESS-DENIED or a network timeout. If the error changes, leave this freshness tree and retain the exact response.[3]
2. Correlate existing driver and server logs
Compare the current query timestamp with existing driver/process and server connection evidence. Distribution service names and paths vary. A now-disconnected driver needs a different diagnosis, not an assertion that every stale response means the driver stopped.[2]
3. Inspect OS visibility and runtime access
Identify the expected USB UPS from existing hardware evidence and compare access/ownership with the installed package's requirements. usbhid-ups does not select its USB hardware by a conventional tty port path; do not import a serial-driver path fix.[6]
4. Separate access conflict from repeated transport errors
Look for actual denied access or duplicate-driver ownership before considering permissions. If communication errors repeat, record their timestamps and model/driver context; one error does not establish a bad cable.[2][6]
5. Reserve timing changes for exact model review
Compare the observed pattern with the applicable driver documentation. Models can have different polling constraints. Do not increase MAXAGE or change polling values simply to remove the warning.[6][4]
Supported scenarios
These observations narrow the next investigation; they do not establish a unique cause.
The driver is not supplying current data
The stale response describes data freshness, not a unique failure of a physical component.[3]
How to check: Match a fresh local query with driver/server evidence for that UPS.[5][2]
USB visibility or access needs investigation
Missing hardware evidence, denied access and competing drivers are distinct observations that warrant different owner checks.[6][2]
How to check: Record device identity and current access/ownership evidence without restarting services.[2]
A documented model-specific pattern may apply
A timing-related hypothesis needs the exact model and matching driver documentation; no universal freshness timeout is established.[4][6]
How to check: Compare repeated timestamps and driver messages with the applicable model notes.[6]
Next actions and procedure boundaries
Device absent: hardware-owner handoff
Provide the expected UPS identity and current OS observations. Ask the responsible operator to investigate the USB path without an automatic unplug, reset or power-cycle test.[6]
Access or duplicate ownership: package-owner review
Provide the actual access denial or competing instance evidence. The package/service owner must establish least-privilege access and the intended driver instance before considering intervention.[2]
Repeated transport errors: driver/model investigation
Send sanitized timestamps, current query result, version and exact model to the driver/package owner. Keep the observed communication failure separate from an unproven hardware diagnosis.[6]
Documented timing match: specialist review only
Provide the exact matching model note and observed pattern. This outcome does not authorize changing MAXAGE, DEADTIME, polling or shutdown policy.[4][6]
Before any separately scoped service or permission intervention
Planning boundary only. The responsible UPS/system operator must consider current power conditions and affected protected systems. This page does not restart services, disconnect USB, disable monitoring or alter shutdown behavior.[7]
Before changing anything
- Risk
- Disrupting NUT communication can impair the information used by shutdown monitoring.[7]
- Safer check
- First confirm the current response and read existing logs. Do not perform a battery test or change power state.[5][7]
- Expected result
- A later owner-approved recovery must restore current data without altering the protection policy; fresh data alone does not validate shutdown behavior.[7]
- Backup / recovery access
- The operator must preserve package/service configuration, identify protected systems, assess current power conditions and establish independent recovery access before intervention.[7]
- Rollback
- No universal service or permission rollback is supplied. Require an installation-specific restoration plan from the owner; if monitoring cannot be recovered safely, do not proceed.[7]
Unresolved freshness: preserve evidence
Keep the UPS name, intended server, current error and timestamped driver/USB observations. Redact credentials and identifiers before a targeted support handoff; do not suppress the warning to claim recovery.[2][5]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-05. Reachability and automated validation do not replace editorial verification of each claim.
- Network UPS Tools - Welcome
Network UPS Tools · Tier A · accessed 2026-09-05 - FAQ
Network UPS Tools · Tier A · accessed 2026-09-05 - 10. Network protocol information
Network UPS Tools · Tier A · accessed 2026-09-05 - UPSD.CONF(5)
Network UPS Tools · Tier A · accessed 2026-09-05 - UPSC(8)
Network UPS Tools · Tier A · accessed 2026-09-05 - USBHID-UPS(8)
Network UPS Tools · Tier A · accessed 2026-09-05 - UPSMON(8)
Network UPS Tools · Tier A · accessed 2026-09-05