Files
wekan/docs/Features/Admin-Panel/Problems/Snap.md
T
Lauri Ojansivu c4a76e0e3d Docs: Admin Panel / Problems — README overview + Snap commands + Repairs / Migrations / Login-Problems pages.
docs/Features/Admin-Panel/Problems/README.md describes what Problems offers and
links the detailed pages (existing CPU/RAM/Disk/Recovery plus the new Repairs,
Migrations, Login-Problems and Snap pages). Snap.md documents `snap run
wekan.problems` and its sub-commands (migrations | login | broken-cards | cpu).
Repairs.md / Migrations.md cover the shared board data-repairs and the MongoDB <->
SQLite migration, when they run (board open, server startup, during migration) and
the progress dashboard. Login-Problems.md explains the "Must be logged in" /
"Loading, please wait" causes and fixes, tying them to a saturated ferretdb.

Thanks to xet7 !
2026-07-22 16:22:39 +03:00

86 lines
3.6 KiB
Markdown

# Admin Panel → Problems: snap commands
Status: **Implemented** · Owner: xet7 · Related: `snap-src/bin/wekan-problems`,
`snap-src/bin/wekan-problems.mjs`, `snapcraft.yaml` (`apps: problems`),
`server/lib/systemStatus.js`, `models/lib/loginProblems.js`,
`models/lib/problemsOverview.js`.
On the **snap**, the Admin Panel → Problems **Status** overview is also available
as plain text from the server command line, so an admin who has server (snap)
access can read it **without** being given Admin Panel access.
The command reads the live database directly over the MongoDB wire protocol
(MongoDB and FerretDB v1/SQLite both speak it; the snap runs one at a time on port
27019), using the bundled Node.js and `mongodb` driver — no `mongosh` needed. It
only **reads**; it never changes anything.
## Commands
```
snap run wekan.problems # full Status overview (default)
snap run wekan.problems migrations # only migrations / repairs in progress
snap run wekan.problems login # only the login-page "Must be logged in" checks
snap run wekan.problems broken-cards # only the broken-cards count
snap run wekan.problems cpu # machine CPU load / core count (no DB needed)
snap run wekan.problems help
```
`migrations` and `repairs` are aliases for the same in-progress list.
## What the overview prints
```
<Product name> Problems — Status
Database: mongodb://127.0.0.1:27019/wekan
In progress:
- Database migration (toFerretDB) — migrating: cards (3/30 collections)
- Board data-repair — 12/40 boards
(or) (none) No migrations or repairs are in progress.
Problems:
- [warning] Broken cards: 5 card(s) with a missing board/list/swimlane or bad type.
- [error] ROOT_URL is not set. ...
(or) (none) No problems detected.
Login page ("Must be logged in" / "Loading, please wait") checks:
[warning] A migration or repair is in progress — ...
[ok] ROOT_URL is set — ROOT_URL=https://boards.example.com ...
...
More: wekan.problems cpu | login | migrations | broken-cards
```
The heading uses the configured **Product name** (Admin Panel → Settings → Layout
→ Product name) when set, otherwise `WeKan`.
## Problem-specific detail: CPU
`snap run wekan.problems cpu` needs no database and prints the machine's core count
and 1/5/15-minute load average:
```
CPU usage
cores: 4 (...)
load average: 3.90 (1m) 3.40 (5m) 2.10 (15m)
uptime: ...
Note: sustained load near or above the core count means the machine is saturated.
A migration/repair (see "wekan.problems") can push CPU up; it drops when it finishes.
```
If `top` shows the **ferretdb** process pegged near 100%/200% for a long time, the
FerretDB v1 (SQLite) backend is saturated under WeKan's poll load — the usual cause
of pages taking minutes, counts stuck at `0`, and raw i18n keys. Mitigations: check
whether a migration/repair is still running (`snap run wekan.problems migrations`),
and consider running on MongoDB instead (`snap set wekan database=mongodb`, then
migrate the text data across — see [Migrations.md](Migrations.md)).
## Notes
- The command connects to `mongodb://127.0.0.1:27019/wekan` by default. Override
with a second argument or the `WEKAN_PROBLEMS_URL` environment variable.
- "In progress" is read from persisted status collections (`text_migration_status`,
`recoveryStatus`, `cronJobStatus`, `attachmentMigrationStatus`), so it stays
correct even if the WeKan server process restarts mid-migration.
- The `login` checks read `ROOT_URL`, `LDAP_ENABLE` and Sandstorm from the
environment, so run the command in the snap's environment for accurate values.