ZP-BLOG - pbsbc01h3相关
type: channel
link: https://zpblog.zhaopeng.site/index.php/category/pbsbc01h3%E7%9B%B8%E5%85%B3/
items: 香橙派podman-compose版本升级
items: 调整journalctl文件后无法启动修复
items: /var/log目录写满问题
items: journald和syslog调整
items: 小开发板配置日志
items: systemd-journald和History日志笔记
items: systemd-journald日志空间问题
items: pbsbc01h3-Chrony时间同步服务
items: pbsbc01h3-ProfileSyncDaemon(psd)配置清理
items: pbsbc01h3日志系统管理相关

香橙派podman-compose版本升级
type: item
date: 2026-05-29T04:36:00+00:00
description: Podman Compose 配置问题排查笔记环境信息设备: Orange Pi Zero 3 (ARM64)系统: Debian BookwormPodman 版本: 4.3.1Podman-compose 版本: 1.0.3 (初始)问题发现1. podman-compose 缺少 config 命令执行 podman-compose config 时出现错误：podman-compose: error: argument command: invalid choice: 'config' (choose from 'help', 'version', 'pull', 'push', 'build', 'up', 'down', 'ps', 'run', 'exec', 'start', 'stop', 'restart', 'logs')原因: podman-compose 1.0.3 版本没有实现 config 命令，这是与 docker-compose 的差异之一。解决方案探索验证当前版本podman-compose --version # 输出: podman-composer version 1.0.3 which podman-compose # 输出: /usr/bin/podman-compose替代验证方法（不升级版本）使用 --dry-run 模拟运行podman-compose up --dry-run使用 Python 验证 YAML 语法python3 -c "import yaml; yaml.safe_load(open('docker-compose.yml'))" && echo "Syntax OK"直接尝试启动（配置有错会报错）podman-compose up -d升级 podman-compose 的过程尝试 1: 使用 pip3 升级（失败）pip3 install --upgrade podman-compose错误信息:error: externally-managed-environment × This environment is externally managed原因: Debian Bookworm 启用了 PEP 668 保护机制，防止破坏系统 Python 环境。尝试 2: 使用 apt 安装（已有版本）apt install podman-compose # 已经安装的是 1.0.3 版本最终方案: 使用 pipx 安装（成功）# 1. 安装 pipx apt install -y pipx # 2. 确保 pipx 路径生效 pipx ensurepath # 3. 重新加载 shell 配置 source ~/.bashrc # 4. 安装 podman-compose pipx install podman-compose # 5. 验证安装 which podman-compose # 现在显示 ~/.local/bin/podman-compose podman-compose --version # 显示新版本重要说明:无需先卸载 apt 安装的旧版本pipx 安装到 ~/.local/bin，优先级高于 /usr/bin系统自动使用新版本安装后验证检查所有安装位置which -a podman-compose # 输出: # /home/root/.local/bin/podman-compose (新版，优先级高) # /usr/bin/podman-compose (旧版) # /bin/podman-compose (旧版链接)测试 config 命令# 查看合并后的配置 podman-compose config # 只验证语法不输出 podman-compose config -q关键知识点podman-compose vs docker-composedocker-compose 有 config 命令podman-compose 低版本（如 1.0.3）没有 config 命令新版 podman-compose 已支持 config 命令Python 环境管理（PEP 668）Debian Bookworm 及更新版本默认保护系统 Python禁止直接用 pip 安装系统级包推荐方案：apt install python3-xyz（Debian 打包的）pipx（隔离的应用程序环境）python3 -m venv（虚拟环境）命令优先级PATH 环境变量决定优先级~/.local/bin 通常优先于 /usr/binwhich -a 显示所有匹配位置后续操作建议验证 frp 配置cd /data/frp podman-compose…

调整journalctl文件后无法启动修复
type: item
date: 2026-05-25T09:05:00+00:00
description: 一、问题背景在解决了 /var/log 磁盘写满问题后，重启开发板发现系统无法正常启动，卡在紧急模式（Emergency Mode），提示需要输入 root 密码进行维护。如下调整后，无法启动，win11DG挂载删除journal文件无效，只能连显示器恢复模式下修改，主要还是修改/etc/fstab开机启动root@pbsbc01h3:~# systemctl stop systemd-journald Warning: Stopping systemd-journald.service, but it can still be activated by: systemd-journald-audit.socket systemd-journald-dev-log.socket systemd-journald.socket root@pbsbc01h3:~# rm -rf /var/log/journal root@pbsbc01h3:~# touch /var/log/journal root@pbsbc01h3:~# chmod 000 /var/log/journal root@pbsbc01h3:~# chattr +i /var/log/journal root@pbsbc01h3:~# mount --bind /dev/null /var/log/journal root@pbsbc01h3:~# echo "/dev/null /var/log/journal none bind 0 0" | sudo tee -a /etc/fstab/dev/null /var/log/journal none bind 0 0 root@pbsbc01h3:~# systemctl start systemd-journald root@pbsbc01h3:~# ls -la /var/log/journal crw-rw-rw- 1 root root 1, 3 May 25 14:37 /var/log/journal root@pbsbc01h3:~# df -h /var/log/ Filesystem Size Used Avail Use% Mounted on /dev/zram0 124M 520K 115M 1% /var/log root@pbsbc01h3:~# reboot 调整了如上配置后，无法启动，win11挂载，删除/var/log/journal目录，还是无法启动，该如何操作二、问题现象系统启动后显示：Give root password for maintenance (or press Control-D to continue):多次输入密码后仍然无法正常启动，最终进入紧急模式。三、问题原因分析3.1 直接原因之前的配置中执行了以下操作：# 创建文件并锁定 touch /var/log/journal chmod 000 /var/log/journal chattr +i /var/log/journal # 绑定挂载并写入 fstab mount --bind /dev/null /var/log/journal echo "/dev/null /var/log/journal none bind 0 0" | sudo tee -a /etc/fstab3.2 根本原因操作导致的问题touch /var/log/journal创建了文件而不是目录chmod 000权限全禁，无法读写chattr +i文件被设为不可变，连 root 也无法删除/修改mount --bind /dev/null覆盖路径，但文件仍被锁定echo ... >> /etc/fstab开机自动执行绑定挂载结果：systemd-journald 启动时无法正常操作 /var/log/journal，导致服务启动失败，系统进入紧急模式。四、解决方案4.1 方案一：在紧急模式中修复（如果可以登录）如果能进入紧急模式并输入 root 密码：# 1. 重新挂载根文件系统为读写 mount -o remount,rw / # 2. 编辑 fstab，删除问题行 nano /etc/fstab # 删除或注释：/dev/null /var/log/journal none bind 0 0 # 3. 删除被锁定的文件 rm -rf /var/log/journal mkdir -p /var/log/journal chmod 755 /var/log/journal # 4. 恢复 journald 配置 cat > /etc/systemd/journald.conf << 'EOF' [Journal] Stor…

/var/log目录写满问题
type: item
date: 2026-05-25T06:37:00+00:00
description: 1核1G开发版 /var/log 目录写满问题终极排查与解决一、问题现象（重启后）重启系统后，发现 /var/log 仍然被写满：/dev/zram0 124M 119M 0 100% /var/logzram 是压缩内存盘，/var/log 挂载在 zram 上可用空间为 0，导致系统异常二、当前配置检查2.1 journald 配置grep -E -v "^\s*(#|$)" /etc/systemd/journald.conf[Journal] Storage=volatile Compress=no SyncIntervalSec=0 RuntimeMaxUse=40M RuntimeMaxFileSize=10M ForwardToSyslog=no ForwardToWall=no2.2 rsyslog 配置grep -E -v "^\s*(#|$)" /etc/rsyslog.confmodule(load="imuxsock") module(load="imklog") $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $WorkDirectory /var/spool/rsyslog $IncludeConfig /etc/rsyslog.d/*.conf auth,authpriv.* /var/log/auth.log kern.crit;kern.emerg /var/log/kern.crit *.emerg :omusrmsg:* *.* stoprsyslog 已最小化配置，只记录 auth 日志和内核紧急日志其他日志已被 *.* stop 丢弃三、问题定位3.1 查看 /var/log 占用详情du -sh /var/log/* | sort -h输出显示：0 /var/log/alternatives.log 0 /var/log/bootstrap.log 0 /var/log/btmp ... 20K /var/log/kern.log 24K /var/log/messages 40K /var/log/pbsbc01h3-hardware-monitor.log 52K /var/log/auth.log 68K /var/log/syslog 92K /var/log/daemon.log 119M /var/log/journal # ← 罪魁祸首！3.2 查看文件大小排序ls -lhS /var/log/ | head -20total 400K -rw-r----- 1 root adm 90K May 25 14:13 daemon.log -rw-r----- 1 root adm 66K May 25 14:13 syslog -rw-r----- 1 root adm 50K May 25 14:22 auth.log -rw-r--r-- 1 root root 40K May 25 14:24 pbsbc01h3-hardware-monitor.log ... drwxr-sr-x+ 3 root systemd-journal 4.0K Apr 2 10:36 journal # 目录占用119M3.3 检查 auth.log 内容tail -100 /var/log/auth.log grep "Failed password" /var/log/auth.log | wc -l输出显示：只有正常的 CRON 和 SSH 登录日志没有失败的密码尝试（0 次）auth.log 只有 50KB，不是问题根源3.4 检查 kern.crit 是否存在ls -lh /var/log/auth.log /var/log/kern.critls: cannot access '/var/log/kern.crit': No such file or directory -rw-r----- 1 root adm 50K May 25 14:22 /var/log/auth.logkern.crit 文件不存在，说明没有内核紧急日志产生四、根本原因问题根源：/var/log/journal/ 目录占用了 119MB，几乎耗尽所有空间。虽然配置了 Storage=volatile，但：Storage=volatile 的语义是：优先使用内存，但如果 /var/log/journal/ 目录已经存在，journald 会继续使用它之前持久化日志留下…

journald和syslog调整
type: item
date: 2026-05-25T06:19:00+00:00
description: 1核1G开发版 /var/log 目录每天12点写满问题排查与解决一、问题现象服务器配置：1核1G 开发版问题：每天中午12点，/var/log 目录被写满检查发现：systemd-journald 是主要占用来源二、初步排查2.1 检查系统定时任务cat /etc/crontab发现系统有标准的 cron 任务，包括每小时、每天、每周、每月的任务调度。2.2 检查 cron.d 目录ls -la /etc/cron.d/发现两个关键脚本被禁用：pbsbc01h3-truncate-logs.disabledpbsbc01h3-ram-logging.disabled2.3 检查清理脚本逻辑cat /usr/lib/pbsbc01h3/pbsbc01h3-truncate-logs脚本功能：当 /var/log 使用率超过 75% 时触发执行：写入SD卡 → logrotate轮转 → truncate清空 → 删除旧文件但依赖 ramlog 且已被禁用三、问题根源定位3.1 真正元凶：systemd-journald# 查看日志占用 du -sh /var/log/ journalctl --disk-usage根本原因：systemd-journald 默认配置不主动限制日志大小，在1核1G开发版上容易写满磁盘。3.2 进一步排查：rsyslogd 也在写入lsof /var/log/* 2>/dev/null发现 rsyslogd 正在写入多个日志文件：/var/log/syslog/var/log/daemon.log/var/log/messages/var/log/kern.log/var/log/auth.log/var/log/user.log结论：问题来自两个组件共同作用：systemd-journald 写 journal 日志rsyslogd 将日志转发写入磁盘文件四、解决方案4.1 方案一：journald 放弃持久化（适合开发板）修改 /etc/systemd/journald.conf：[Journal] # 核心：只存内存 Storage=volatile # 内存大小限制 RuntimeMaxUse=40M RuntimeMaxFileSize=10M # 性能优化 Compress=no SyncIntervalSec=0 # 防刷屏 RateLimitIntervalSec=10s RateLimitBurst=200 # 日志转发（建议关闭） ForwardToSyslog=no ForwardToWall=no应用配置：sudo systemctl restart systemd-journald sudo journalctl --rotate sudo journalctl --vacuum-size=1M sudo rm -rf /var/log/journal/*4.2 方案二：处理 rsyslogd选项A：完全禁用 rsyslog（最推荐）sudo systemctl stop rsyslog sudo systemctl disable rsyslog # 清理现有日志 sudo find /var/log -name "*.log" -exec truncate -s 0 {} \; 2>/dev/null sudo find /var/log -name "*.log.*" -delete 2>/dev/null选项B：最小化 rsyslog 配置备份原配置后，创建最小配置只保留关键日志（auth、kern.crit）：sudo tee /etc/rsyslog.conf > /dev/null << 'EOF' module(load="imuxsock") module(load="imklog") $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $WorkDirectory /var/spool/rsyslog $IncludeConfig /etc/rsyslog.d/*.conf # 只记录关键日志 auth,authpriv.* /var/log/auth.log kern.crit;kern.emerg /var/log/kern.crit *.emerg :omusrmsg:* # 丢弃其他所有日志 *.* stop EOF sudo systemctl restart rsyslog选项C：激进 logrotate 策略创建 /etc/logrotate.d/rsyslog-aggressive：/var/log/syslog /var/log/messages /var/log/kern…

小开发板配置日志
type: item
date: 2026-05-23T16:27:00+00:00
description: Linux 系统日志磁盘写满问题排查与解决笔记1. 问题现象系统每天凌晨 00:00 左右，/var/log 目录所在分区磁盘空间被写满。系统日志（/var/log/syslog、/var/log/daemon.log 等）出现大量如下错误：cat: write error: No space left on device rsyslogd: file '/var/log/syslog' write error - No space left on device系统为 Armbian 定制版，运行在 1核1G ARM 开发板（如 Orange Pi、Banana Pi 等）上，内核版本 5.4.65-sunxi。2. 问题初步分析2.1 磁盘空间检查df -h df -i发现 /var/log 分区使用率接近 100%，且存在大量 systemd journal 的僵尸文件（以 .journal~ 结尾）。2.2 日志目录分析du -sh /var/log/* ls -la /var/log/journal/*/发现 /var/log/journal/ 下存在大量类似以下文件：system@xxx.journal~这些文件是 journald 轮转后未能自动清理的残留文件，占用了几十 MB 甚至更多空间。3. 根本原因定位3.1 定时任务排查查看系统定时任务：cat /etc/crontab ls -la /etc/cron.d/ ls -la /etc/cron.daily/发现关键定时任务：/etc/cron.d/pbsbc01h3-truncate-logs 每 15 分钟执行一次/etc/cron.d/pbsbc01h3-updates 每天和重启时执行/etc/cron.daily/pbsbc01h3-ram-logging 每天执行一次3.2 问题脚本内容分析查看 pbsbc01h3-truncate-logs 脚本：cat /usr/lib/pbsbc01h3/pbsbc01h3-truncate-logs脚本逻辑如下：检查 /var/log 磁盘使用率是否 ≥ 75%。如果超过阈值：调用 pbsbc01h3-ramlog write 将内存中的日志同步到磁盘。强制运行 logrotate。暴力截断所有日志文件内容（truncate --size 0）。删除旧的压缩日志（*.gz、*.[0-9]）。3.3 问题机制总结该脚本与 systemd-journald 同时操作日志文件，产生冲突。冲突导致 journald 轮转时无法正确清理旧文件，遗留大量 .journal~ 僵尸文件。僵尸文件不断累积，最终在凌晨触发日志同步时占满磁盘空间。4. 解决方案4.1 立即清理僵尸文件# 停止 systemd-journald sudo systemctl stop systemd-journald # 删除所有 journal 僵尸文件 sudo find /var/log -name "*.journal~" -type f -delete # 强制 journald 遵守 80MB 大小限制 sudo journalctl --vacuum-size=80M # 重启 systemd-journald sudo systemctl start systemd-journald4.2 禁用问题定时任务（推荐）# 禁用每15分钟执行的日志截断任务 sudo mv /etc/cron.d/pbsbc01h3-truncate-logs /etc/cron.d/pbsbc01h3-truncate-logs.disabled # 禁用每日执行的 ramlog 写入任务（可选，减少冲突） sudo mv /etc/cron.daily/pbsbc01h3-ram-logging /etc/cron.daily/pbsbc01h3-ram-logging.disabled4.3 保持 ramlog 启用（可选）如果希望继续保护 SD 卡写入寿命，可以保持 ramlog 启用：# 编辑 /etc/default/pbsbc01h3-ramlog sudo nano /etc/default/pbsbc01h3-ramlog确保配置如下：ENABLED=true SIZE=128M USE_RSYNC=true注意：不要添加 XTRA_RSYNC_OPTS=(--delete) 等额外参数，否则可能产生冲突。5. 验证与监控5.1 验证清理效果# 检查磁盘使用率 df -h # 检查僵尸文件是否还存在 find /var/log -name "*.journal~" | wc -l # 检查 journal 实际占用 journalc…

systemd-journald和History日志笔记
type: item
date: 2026-05-01T11:36:00+00:00
description: Linux systemd-journald 日志与 Bash History 完全指南一、/var/log/journal 是什么？/var/log/journal 是 systemd-journald 服务存放结构化系统日志的目录。它是 Linux 系统事件的中央数据库。记录的内容几乎所有系统层面的操作都会被记录：内核报错、硬件异常用户登录、登出（SSH、本地）服务启动、停止、崩溃程序错误输出网络连接变化系统安全事件查看方式# 查看所有日志 journalctl # 查看最近 1 小时的日志 journalctl --since "1 hour ago" # 查看特定服务的日志 journalctl -u ssh.service # 查看内核日志 journalctl -k # 查看日志占用空间 journalctl --disk-usage二、/var/log/journal 是必须的吗？不是绝对必须，但强烈建议保留。保留的理由场景重要性排查程序闪退、系统报错⭐⭐⭐⭐⭐ 核心工具安全审计（异常登录、关键操作）⭐⭐⭐⭐⭐服务调试（查看实时输出）⭐⭐⭐⭐性能问题定位⭐⭐⭐⭐关闭的后果系统故障时，没有任何日志可查安全事件无法追溯技术支持/社区求助时无法提供日志比喻：就像飞机没有黑匣子——能飞，但出事就傻眼。三、如何减少或关闭日志？方案一：限制大小（推荐）编辑 /etc/systemd/journald.conf：[Journal] Compress=yes SystemMaxUse=120M # 持久日志总大小上限 SystemMaxFileSize=30M # 单个日志文件大小 SystemMaxFiles=4 # 最多保留文件数 RuntimeMaxUse=20M # 运行时日志上限（内存） MaxRetentionSec=2day # 最长保留 2 天生效命令（无需重启服务器）：systemctl restart systemd-journald journalctl --vacuum-size=120M方案二：关闭持久化（日志只存内存）[Journal] Storage=volatile生效命令：systemctl stop systemd-journald rm -rf /var/log/journal/* systemctl start systemd-journald效果：重启后所有历史日志丢失，不占用磁盘空间。方案三：彻底关闭（不推荐）[Journal] Storage=none三种方案对比方案占用空间重启后日志排查能力推荐度限制大小固定上限保留完整⭐⭐⭐⭐⭐易失存储0（仅内存）丢失仅当前⭐⭐⭐完全关闭0无日志无法排查⭐四、history 命令历史存在 /var/log/journal 里吗？不存在。 两者是完全独立、不同层级的系统。对比表对比项history 历史/var/log/journal 日志存储位置~/.bash_history（用户目录）/var/log/journal/（系统目录）记录内容用户输入的 shell 命令系统事件、服务日志、内核消息归属用户级别（每个用户独立）系统级别（所有进程共享）查看方式history 命令journalctl 命令主要用途用户回顾/复用命令系统故障排查、安全审计各用户的 history 文件位置/root/.bash_history # root 用户 /home/用户名/.bash_history # 普通用户history 工作流程（重要）flowchart LR A[终端启动] --> B[从 .bash_history 读取 历史到内存] B --> C[输入命令 暂存在内存] C --> D[正常退出终端 exit 或 logout] D --> E[内存中的命令 追加写入 .bash_history]关键点：当前终端的命令不立即写入文件正常退出终端时才写入直接关闭窗口可能导致最后几条命令丢失常用 history 管理命令history # 查看历史（内存+文件） cat ~/.bash_history # 查看文件原始内容 history -a # 立即将内存命令写入文件 history -c # 清空当前终端内存历史五、想集中记录命令历史到 systemd 日志？可以通过配置实现（用于审计，但会显著增加日志量）：# 在 ~/.bashrc 中添加 export PROMPT_COMMAND='history -a >(logger -t "bash_history_$(whoami)")' # 或使用 auditd auditctl -a always,exit -S execve -k shell_commands根据你的 128M /var/l…

systemd-journald日志空间问题
type: item
date: 2026-05-01T11:14:00+00:00
description: Linux systemd-journald 日志空间问题排查与配置笔记一、环境信息系统: Linux pbsbc01h3 5.4.65-sunxi #2.2.2 SMP Fri Mar 15 19:06:30 CST 2024 armv7l GNU/Linux日志存储: /var/log 挂载在 zram 压缩内存盘上，总容量 128MB初始问题: 不到一天 /var/log 使用率达到 100%# 查看磁盘使用情况 df -h /var/log # 输出: /dev/zram0 124M 122M 0 100% /var/log # 查看日志占用 journalctl --disk-usage # 输出: Archived and active journals take up 176.9M in the file system.二、问题诊断1. 存储结构zramctl # NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT # /dev/zram1 lzo-rle 499.8M 4K 73B 4K 4 [SWAP] # /dev/zram0 zstd 128M 121.5M 8.8M 9.5M 4 /var/log2. 日志占用详情du -sh /var/log/* 2>/dev/null | sort -h占用目录/文件说明121M/var/log/journalsystemd 日志 ← 主要占用276K/var/log/wtmp登录记录100K/var/log/lightdm显示管理器日志28K/var/log/auth.log认证日志28K/var/log/daemon.log守护进程日志12K/var/log/user.log用户日志8K/var/log/syslog系统日志其他各种小文件合计不足 1M结论: /var/log/journal 占用 121M / 128M，是问题根源。三、原始配置及问题分析原始配置Compress=yes SystemMaxUse=50M SystemKeepFree=100M # ← 问题根源 SystemMaxFileSize=10M SystemMaxFiles=4 RuntimeMaxUse=50M RuntimeKeepFree=50M # ← 潜在问题 RuntimeMaxFileSize=10M MaxRetentionSec=4day配置冲突说明配置项设定值问题SystemMaxUse50M要求日志最多占 50MSystemKeepFree100M要求磁盘至少空闲 100M/var/log 总容量128M128M - 100M = 28M 可用给日志实际效果: journald 优先满足 SystemKeepFree，导致日志实际上限被压缩到 28M，与 SystemMaxUse=50M 产生直接冲突。四、解决方案方案一：优化配置（推荐）修改 /etc/systemd/journald.conf：[Journal] Compress=yes SystemMaxUse=120M # 充分利用 128M 空间 # SystemKeepFree=100M # 注释掉或删除 SystemMaxFileSize=30M # 单文件 30M，减少文件数量 SystemMaxFiles=4 RuntimeMaxUse=20M # 运行时日志不需要太大 # RuntimeKeepFree=50M # 注释掉 RuntimeMaxFileSize=10M MaxRetentionSec=2day # 从 4 天改为 2 天保守版配置（给其他日志留空间）[Journal] Compress=yes SystemMaxUse=110M SystemKeepFree=10M # 改成 10M 而不是 100M SystemMaxFileSize=25M SystemMaxFiles=4 RuntimeMaxUse=20M RuntimeMaxFileSize=10M MaxRetentionSec=2day立即生效命令# 1. 编辑配置文件 nano /etc/systemd/journald.conf # 2. 重启 journald 服务 systemctl restart systemd-journald # 3. 强制清理到指定大小 journalctl --vacuum-size=120M # 4. 验证效果 df -h /var/log journalctl --disk-usage方案二：关闭 zram 日志存储（改用硬盘）临时关闭（重启失效）：systemctl stop systemd-journal-…

pbsbc01h3-Chrony时间同步服务
type: item
date: 2026-04-02T03:53:00+00:00
description: Chrony 时间同步服务完全指南目录Chrony 简介Chrony 架构与组件配置文件详解常用命令与操作常见问题与排查性能优化与最佳实践故障案例实战Chrony 简介什么是 ChronyChrony 是一个用于保持系统时间与 NTP（Network Time Protocol）服务器同步的服务。它是传统 ntpd 的现代替代品，特别适合：不总是联网的系统（如笔记本电脑、物联网设备）虚拟机和云环境（时间容易漂移）需要快速同步的系统（启动后几秒内完成同步）Chrony vs NTPd 对比特性ChronyNTPd启动速度快（几秒同步）慢（需几分钟）网络中断适应优秀（自动补偿）一般虚拟化支持优秀（检测漂移）一般资源占用低（内存约 1MB）较高配置复杂度简单复杂时钟调整方式支持步进和微调仅微调Chrony 架构与组件核心组件组件作用进程名配置文件chronyd守护进程，核心服务chronyd/etc/chrony/chrony.confchronyc命令行客户端，监控和管理chronyc-工作流程NTP 服务器池 (pool.ntp.org) ↓ chronyd 守护进程 ↓ ├─→ 系统时钟同步 ├─→ 硬件时钟 (RTC) 同步 └─→ 时间漂移补偿 ↓ chronyc 监控工具数据存储位置# 配置文件 /etc/chrony/chrony.conf # 主配置文件 /etc/chrony/chrony.keys # 认证密钥文件 /var/lib/chrony/chrony.drift # 时钟漂移文件 /var/lib/chrony/chrony.sock # 命令套接字 # 日志文件 /var/log/chrony.log # 日志（需配置） journalctl -u chrony # systemd 日志配置文件详解主配置文件结构cat /etc/chrony/chrony.conf1. NTP 服务器配置# 使用公共 NTP 服务器池 pool 0.pool.ntp.org iburst pool 1.pool.ntp.org iburst pool 2.pool.ntp.org iburst # 或使用特定服务器 server ntp.aliyun.com iburst server time.google.com iburst # 参数说明： # pool - 服务器池（自动轮询） # server - 指定服务器 # iburst - 初始快速同步（发送4-8个包）2. 时间同步策略# 允许系统时钟步进（快进/后退） # 前3次同步如果偏差超过1秒，立即步进 makestep 1 3 # 启用硬件时钟同步 rtcsync # 时钟漂移文件位置 driftfile /var/lib/chrony/chrony.drift3. 访问控制# 允许本机查询 allow 127.0.0.1 allow ::1 # 允许局域网客户端（Chrony 可作为服务器） allow 192.168.1.0/24 # 拒绝所有 deny all4. 日志配置# 日志文件 logdir /var/log/chrony # 记录测量统计 log measurements statistics tracking完整配置示例# /etc/chrony/chrony.conf 完整示例 # NTP 服务器 pool time.google.com iburst pool ntp.aliyun.com iburst # 初始步进设置 makestep 0.1 3 # 硬件时钟 rtcsync # 漂移文件 driftfile /var/lib/chrony/chrony.drift # 命令套接字 cmdport 323 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 # 本地访问控制 allow 127.0.0.1 allow ::1 # 日志 logdir /var/log/chrony log measurements statistics tracking # 密钥认证（如需要） # keyfile /etc/chrony/chrony.keys常用命令与操作服务管理# systemd 管理 systemctl start chronyd # 启动服务 systemctl stop chronyd # 停止服务 systemctl restart chronyd # 重启服务 systemctl status chronyd # 查看状态 systemctl enable chronyd # 开机自启 systemctl disable chronyd # 禁用自启 # 查看日志 journalc…

pbsbc01h3-ProfileSyncDaemon(psd)配置清理
type: item
date: 2026-04-02T03:32:00+00:00
description: Profile Sync Daemon (psd) 完整指南目录什么是 psdpsd 的工作原理psd 的组件常见问题与故障问题诊断方法解决方案彻底清理方法预防措施什么是 psdProfile Sync Daemon (psd) 是一个用于将浏览器配置文件同步到内存的守护程序，主要目的是：提升浏览器性能：将浏览器配置（书签、历史记录、Cookie 等）从硬盘移到内存中运行保护存储设备：减少对硬盘/SD卡的频繁写入，延长存储设备寿命加快启动速度：内存读取速度远快于硬盘适用场景树莓派等使用 SD 卡的设备机械硬盘系统需要保护存储设备的嵌入式系统不适用场景服务器环境（如 Proxmox Backup Server）没有图形界面和浏览器的系统内存紧张的设备psd 的工作原理核心机制硬盘（配置文件） → 内存（运行时） → 定期同步 → 硬盘（持久化）启动时：将浏览器配置从硬盘复制到内存运行时：浏览器使用内存中的配置（读写速度更快）定期同步：通过定时服务将内存中的改动写回硬盘关机时：最后一次同步，确保数据不丢失数据流向浏览器 ←→ 内存（/dev/shm） ←→ 硬盘（~/.mozilla 等） ↑ ↑ | | psd 管理 定期同步psd 的组件1. 主要服务服务名称作用状态psd.service主服务，负责初始化和同步系统启动时运行psd-resync.service定时同步服务按定时器触发psd-resync.timer定时器，触发同步任务定期执行2. 相关文件位置# 服务文件 /usr/lib/systemd/user/psd.service /usr/lib/systemd/user/psd-resync.service /usr/lib/systemd/user/psd-resync.timer # 符号链接 /etc/systemd/user/default.target.wants/psd.service /etc/systemd/user/default.target.wants/psd-resync.service /etc/systemd/user/timers.target.wants/psd-resync.timer # 配置文件 /etc/psd.conf ~/.config/psd/ ~/.cache/psd/ # 执行文件 /usr/bin/psd /usr/bin/profile-sync-daemon3. 支持同步的浏览器FirefoxChromium / ChromeOperaBraveVivaldi常见问题与故障问题1：服务启动失败Failed to start Timed resync Main process exited, code=exited, status=1/FAILURE原因：没有安装任何浏览器psd 配置错误浏览器配置文件不存在问题2：日志风暴# journal 日志快速增长 system.journal 持续写入原因：psd-resync 服务持续失败并记录错误定时器每分钟/每小时触发一次每次失败都写入系统日志问题3：服务无法禁用# 即使运行 disable，服务仍显示 enabled systemctl --user disable psd-resync.service # 状态仍为 "enabled"原因：符号链接未完全删除systemd 缓存未刷新服务被多个位置引用问题4：残留服务状态● psd-resync.service not-found failed failed ● psd.service not-found failed failed原因：服务文件已删除，但 systemd 仍记录失败状态需要手动重置失败状态问题诊断方法1. 检查服务状态# 查看用户服务状态 systemctl --user status psd-resync.service systemctl --user status psd.service # 查看所有 psd 相关服务 systemctl --user list-units | grep psd # 查看失败的服务 systemctl --user --failed2. 检查配置文件# 查看 psd 配置 cat /etc/psd.conf # 查看支持的浏览器 psd list # 检查是否安装浏览器 which firefox chromium3. 查看错误日志# 查看 psd 相关日志 journalctl --user -u psd-resync.service -n 20 journalctl --user -u psd.service -n 20 # 查看系统错误 journalctl -p 3 | grep -i psd…

pbsbc01h3日志系统管理相关
type: item
date: 2026-04-02T03:26:00+00:00
description: Linux 日志系统管理完整指南目录日志系统架构zram 设备管理Armbian Ramlog 详解Systemd Journald 配置日志清理与维护监控与自动化最佳实践日志系统架构两种日志系统的关系应用程序/服务 ↓ systemd-journald (日志收集器) ↓ /var/log/journal/ (日志存储) ↓ armbian-ramlog (存储位置管理) ↓ zram0 (压缩内存设备) → 定期同步 → /var/log.hdd (磁盘备份)核心组件对比组件作用存储位置主要命令systemd-journald日志收集器，收集所有系统日志/var/log/journal/ (持久化)/run/log/journal/ (运行时)journalctlarmbian-ramlog日志存储管理器，将 /var/log 放入内存/var/log (内存)/var/log.hdd (磁盘备份)armbian-ramlog synczram压缩内存块设备/dev/zram0, /dev/zram1zramctlzram 设备管理查看 zram 状态# 查看所有 zram 设备 zramctl # 输出示例 NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram1 lzo-rle 499.8M 4K 73B 4K 4 [SWAP] /dev/zram0 zstd 128M 2.6M 551K 988K 4 /var/logzramctl 输出字段说明字段说明NAME设备名称ALGORITHM压缩算法 (lzo-rle, zstd, lz4 等)DISKSIZE分配的磁盘大小DATA实际数据大小COMPR压缩后大小TOTAL总占用内存（包含元数据）STREAMS压缩流数量MOUNTPOINT挂载点（如有）zram 设备操作命令# 重置 zram 设备（清空数据） sudo zramctl -r /dev/zram0 # 创建新 zram 设备 sudo zramctl /dev/zram0 --algorithm zstd --size 128M # 调整设备大小 echo 0 > /sys/block/zram0/disksize # 清空 echo 256M > /sys/block/zram0/disksize # 重新设置大小 # 查看设备统计信息 cat /sys/block/zram0/statzram stat 字段说明字段顺序: 读取次数, 合并读, 读取扇区数, 读耗时(ms), 写入次数, 合并写, 写入扇区数, 写耗时(ms), IO进行中, IO耗时(ms), 加权IO耗时(ms)Armbian Ramlog 详解配置文件位置/etc/default/armbian-ramlog # 主配置 /etc/default/pbsbc01h3-ramlog # 特定设备配置（如有）配置参数说明# 启用/禁用 ramlog ENABLED=true # 分配的内存大小 SIZE=128M # 使用 rsync 同步（性能更好） USE_RSYNC=true # rsync 额外参数（删除硬盘上已不存在的文件） XTRA_RSYNC_TO=(--delete)ramlog 工作原理启动时：从磁盘 /var/log.hdd 恢复到内存 /var/log运行时：所有日志写入内存中的 /var/log定期同步：通过 cron 或服务将内存日志同步到磁盘关机时：将内存日志同步到磁盘保存常用操作命令# 手动同步内存日志到磁盘 /usr/lib/armbian/armbian-ramlog sync # 重启 ramlog 服务 systemctl restart armbian-ramlog # 查看服务状态 systemctl status armbian-ramlog # 临时禁用 ramlog systemctl stop armbian-ramlog umount /var/log调整 ramlog 大小# 修改配置文件 sed -i 's/SIZE=128M/SIZE=256M/' /etc/default/armbian-ramlog # 重启服务生效 systemctl restart armbian-ramlog # 验证 df -h /var/log zramctlSystemd Journald 配置配置文件位置/etc/systemd/journald.conf # 主配置文件 /etc/systemd/journald.conf.d/*.conf # 配置片段（推荐）推荐配置（限制日志大小）# 创建配置目录 mk…