Collect diagnostics on Linux

Use this page when a collector on a Linux host needs diagnosing — a failed update, a lost connection, data not reaching destinations, or a service that won't start. One command collects everything support needs into a single archive: run it when our support team asks for it, or attach it proactively when opening a ticket to speed up the resolution.

Works on any systemd-based distro this package supports. Takes about a minute.

What the script does — and does not do

The script is strictly read-only:

• It does not stop, restart, or reconfigure the collector or any system service.
• No reboot is needed, and it is safe to run during business hours.
• It is plain, readable POSIX shell — your security team is welcome to review it before running, and the archive it produces contains only readable text files you can inspect before sending.

It collects: the collector's own log files, its systemd service and unit status, configuration files (passwords and tokens are automatically redacted), and journald excerpts from the last 4 days by default — the collector's own unit, its update/uninstall companion units, system-wide service activity, and system-wide error-priority-and-above entries (adjustable — see Options) — plus crash-report folder names and dates (systemd-coredump/apport/abrt, if present) that fall outside that window.

Scope note on event logs: the journal excerpts are system-wide — they include the system's own records of other software's service activity in the window (unit names, timestamps, and exit codes as logged by systemd/journald). This matters because a very common cause of update failures is another service or package update running at the same moment, which is only visible in those neighboring entries. No other application's files, logs, or data are collected — only systemd's journal entries about them.

It never collects: your telemetry/log data (buffered queue contents are excluded — only file names and sizes are listed), credentials, or the collector's encrypted secret files.

Run it

Open a terminal with sudo access (this matters: without it, service state, some logs, and journal entries cannot be read), paste this single line, and press Enter:

sudo bash -c "$(curl -k -L https://storage.googleapis.com/download_dev/collect-praxis-diag.sh)"

When it finishes, it prints the result path. Attach this file to your support ticket:

praxis-collector-support-<hostname>-<timestamp>.tar.gz

(written to the current directory by default — see Options to change that). The archive contains a manifest.txt listing everything collected — and anything that was skipped, with the reason.

Timing matters

The event-log capture covers the last 4 days by default. Run the script soon after the problem occurs. If the failure is older than that, retry the operation once and run the script right after, or use --from-date/--to-date (see Options) if you already know the incident window.

Options

Append these after the download command (a -- separates the downloaded script's own options from curl's):

sudo bash -c "$(curl -k -L https://storage.googleapis.com/download_dev/collect-praxis-diag.sh)" -- --since-hours 336

Option	Effect
--since-hours 6	Narrows the event-log window to 6 hours — useful right after reproducing the problem, and it minimizes unrelated system activity in the bundle
--since-hours 336	Widens the window (here, 14 days) — only when support asks for it, for incidents too old for the default
--from-date "2026-07-01 00:00:00" --to-date "2026-07-05 23:59:59"	Collects an exact date/time range instead of a rolling lookback — use this when you already know the incident window
--output-dir /some/folder	Writes the archive somewhere other than the current directory

If something goes wrong

• curl: command not found — some minimal/hardened images don't ship curl. Download collect-praxis-diag.sh on any other machine (or with wget), copy it to the host, then run:

  sudo sh collect-praxis-diag.sh

• "WARNING: not running as root" — the script continues but skips protected logs. Re-run with sudo for a complete bundle.

• "Could not create the archive automatically" — the script prints the folder it collected into. Run tar -czf <name>.tar.gz <folder> from that location, and attach that archive instead.

• journalctl: command not found — on a non-systemd or minimal host, the script falls back to grepping /var/log/syslog / /var/log/messages directly (noted in the manifest as "not precisely time-bounded").

• Blocked by antivirus/EDR/security tooling — the script is unsigned POSIX shell, which some security products flag. It is safe to review (plain text) and allowlist; ask your security team to inspect it first if required.

If the script errors in any other way, send us whatever it produced anyway — the manifest records what it could not collect and why, which is useful to us too.