使用 journalctl --user 审计非特权账号定时服务，需先确认 systemd --user 实例活跃（State=active、Service=systemd），启用 linger 保障会话持久化，再通过 systemctl --user list-timers 查看定时器，用 journalctl --user -u xxx.service 查日志，结合 -p 3、--grep、-o json-pretty 等选项分析触发、失败与权限问题，并配置 ~/.config/systemd/journald.conf 实现日志持久化与结构化导出。
使用 journalctl --user 审计非特权账号的定时服务，关键在于区分用户级 systemd 实例与系统级日志，并确保目标服务确实在用户 session 中运行（即通过 systemd --user 启动，而非系统 unit）。这类服务常见于桌面环境或无 root 权限的长期后台任务（如定期同步、通知检查、本地数据聚合等）。
确认用户级 systemd 已启用并活跃
非特权账号的定时服务依赖 systemd --user 实例。若未启动，--user 日志为空：
- 检查用户 manager 是否运行：
loginctl show-user $USER | grep -i "state\|service"，输出中State=active且Service=systemd表示正常 - 若未运行，手动启动：
systemctl --user daemon-reload && systemctl --user start default.target - 确保用户登录会话持久化（避免登出后服务停止）：启用 linger：
sudo loginctl enable-linger $USER
定位并查看目标定时服务日志
用户定时服务本质是 .timer + .service 单元对，日志归属 --user 空间：
- 列出当前用户所有 timer：
systemctl --user list-timers --all - 查看某定时服务（如
backup-daily.timer）触发的 service 日志：journalctl --user -u backup-daily.service - 若 service 名不明确，可按时间范围+关键词过滤：
journalctl --user --since "2026-05-19" --grep "backup\|sync"
审计关键行为：触发、执行失败与权限边界
非特权服务的异常往往体现在权限拒绝、路径不可写、环境缺失等，需结合字段分析：
- 检查是否因权限被拒而失败：
journalctl --user -u your-service.service -p 3 | grep -i "permission\|denied\|no such file" - 验证定时器是否真正触发（对比 timer 和 service 日志时间戳）：
journalctl --user -u your-service.timer -o short-iso和journalctl --user -u your-service.service -o short-iso - 查看完整上下文（含 UID、Home、环境变量）：
journalctl --user -u your-service.service -n 20 -o json-pretty | jq 'select(.UID==1001)'（替换为实际 UID）
持久化与导出用于合规审查
用户日志默认不跨重启持久保存，需主动配置才能满足审计留存要求：
- 启用用户日志持久化（需用户有写权限）：
mkdir -p ~/.local/share/systemd/journal - 设置最大日志大小（在
~/.config/systemd/journald.conf中）：SystemMaxUse=100M - 导出指定时间段的结构化审计记录：
journalctl --user --since "2026-05-01" --until "2026-05-20" -u your-service.service -o json > audit-202605.json
