systemd管理nginx启动失败需依次检查服务状态与日志、配置语法及路径、用户权限与运行目录、端口占用及selinux/apparmor限制。
直接用 Docker 跑最稳，二进制方式容易卡在权限、路径、systemd 服务配置这三关——尤其是 vikunja 进程默认以非 root 用户身份运行，但你手动解压后没改 files 和 db 目录的 UID/GID，启动就报 permission denied。
docker run 启动时挂载目录权限不对，容器直接退出
这是新手最常踩的坑：Docker 容器内 vikunja 默认以 UID 1000 运行，但宿主机上 vikunja/files 和 vikunja/db 目录属于 root 或其他用户，导致无法写入。
- 必须提前执行
chown -R 1000:1000 vikunja/，不能只改目录本身，files/和db/子目录也要覆盖 - 如果用的是 Unraid 或某些 NAS 系统，注意它的共享目录默认挂载为 root 权限，得在 WebUI 里手动设成「允许自定义 UID」或改用 Docker Compose 的
user: "1000:1000"显式指定 -
docker run命令里别漏掉-v $(pwd)/vikunja/files:/app/vikunja/files—— 路径少一个/app前缀，文件就存到容器根目录，重启后全丢
用 docker-compose 切 MySQL 时连不上数据库
错误现象通常是容器日志里反复打印 failed to connect to database: dial tcp: lookup mariadb on 127.0.0.11:53: no such host，或者 access denied for user 'vikunja'@'172.x.x.x'。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 确保
depends_on只控制启动顺序，不保证 MySQL 已 ready；加healthcheck或用wait-for-it.sh脚本更可靠 -
VIKUNJA_DATABASE_HOST必须填服务名（如mariadb），不是localhost或127.0.0.1—— Docker 网络里localhost指容器自己 - MySQL 容器初始化时，
MYSQL_DATABASE和VIKUNJA_DATABASE_NAME必须一致；同时确认VIKUNJA_DATABASE_USER在 MySQL 里有对应账号且允许从%或具体网段登录
二进制安装后 systemd 服务起不来
常见报错：Failed at step EXEC spawning /opt/vikunja/vikunja: Permission denied，或 WorkingDirectory=... does not exist。
-
ExecStart路径必须是绝对路径，且vikunja文件要有+x权限：chmod +x /opt/vikunja/vikunja -
WorkingDirectory必须设成/opt/vikunja或其他含config.yml的目录，否则它找不到配置，会 fallback 到内置默认值，连 SQLite 都可能写错位置 - 别直接用 root 启动；在 service 文件里加
User=1000和Group=1000，并确保/opt/vikunja/files和/opt/vikunja/db所属 UID/GID 是 1000
SQLite 看似简单，但并发写入时容易触发 database is locked —— 尤其多人共用或前端频繁刷新。生产环境真要用数据库，MySQL 或 PostgreSQL 不是可选项，是必选项。
