关于Linux中的日志问题

Linux嵌入式开发中遇到的一些日志相关问题linux终端通常不刷屏日志我linux明明起了很多应用也有日志打印为啥没有任何日志显示只有一个空终端你看到的终端界面只有空命令行没有任何应用日志输出这是Linux 日志输出位置的典型问题应用 / 内核的日志默认不会直接打印到当前终端而是输出到专门的日志文件或系统日志服务中。 为什么看不到日志日志重定向应用启动时标准输出 / 错误stdout/stderr被重定向到了/dev/null、日志文件或系统日志服务而不是当前终端。系统日志服务接管现代 Linuxsystemd 系统的日志由journald统一管理应用 / 服务日志不会直接打在终端。前台 / 后台差异如果应用是后台运行或 systemd 服务日志不会出现在当前 shell。️ 查看日志的正确方法1. 查看 systemd 服务日志最常用如果你的应用是通过systemd管理的服务# 实时查看服务日志-f 表示 follow类似 tail -f journalctl -u 你的服务名.service -f # 查看最近 100 行日志 journalctl -u 你的服务名.service -n 100 # 按时间过滤今天的日志 journalctl -u 你的服务名.service --since today2. 查看应用自身的日志文件很多应用会将日志写入固定路径常见位置/var/log/下的应用目录如/var/log/nginx/、/var/log/appname/应用安装目录下的logs/文件夹应用启动时指定的日志文件如./app app.log 21查看示例# 实时查看应用日志 tail -f /var/log/你的应用名.log3. 查看内核 / 驱动日志dmesg如果是内核 / 驱动相关日志# 实时查看内核日志 dmesg -w # 过滤蓝牙相关日志 dmesg -w | grep -i bluetooth4. 查看所有系统日志如果不确定日志归属直接看全系统日志# 实时查看所有日志 journalctl -f5. 前台运行应用直接看输出如果想让日志直接打印到当前终端前台启动应用# 停止后台服务 systemctl stop 你的服务名.service # 前台运行应用日志直接输出 ./你的应用程序此时所有stdout/stderr都会打印在当前终端。 关键排查点确认应用是否在后台运行ps aux | grep 你的应用名确认应用启动脚本查看是否有 /dev/null 21这类重定向语句确认系统日志服务systemctl status systemd-journald必须运行✅ 总结日志不会自动出现在终端需要通过journalctl、tail -f或前台启动来查看。优先用journalctl -u 服务名 -f排查服务类应用用tail -f 日志文件排查自定义日志的应用。dmesgdmesg全称display message是 Linux 下查看内核环形缓冲区日志的命令专门用来展示内核启动、硬件检测、驱动加载、设备事件等底层信息。它的核心作用是告诉你内核和硬件到底发生了什么是排查硬件 / 驱动问题的 “第一入口”。✨ 核心特点来源日志来自内核的环形缓冲区ring buffer记录内核从启动到当前的所有关键事件。内容硬件枚举CPU、内存、USB、PCIe、蓝牙、Wi-Fi 等设备的检测驱动加载 / 卸载比如btusb、ath9k等驱动的初始化固件加载比如蓝牙 / 显卡固件是否成功下载到硬件设备异常比如硬件断开、驱动报错、资源冲突特点日志不会自动打印到终端需要用dmesg主动读取日志会循环覆盖旧信息会被新信息顶掉。 常用命令示例# 1. 查看所有内核日志从开机到现在 dmesg # 2. 实时滚动查看新日志类似 tail -f dmesg -w # 3. 过滤关键词比如蓝牙、Wi-Fi、USB dmesg | grep -i bluetooth dmesg | grep -i wifi dmesg | grep -i usb # 4. 查看最近 50 行日志 dmesg | tail -50 # 5. 带时间戳查看更易读 dmesg -T⚠️ 典型应用场景硬件没反应比如蓝牙 / USB 设备插了没反应 → 用dmesg看内核有没有检测到硬件。驱动加载失败比如hciconfig提示No such device→ 用dmesg | grep bluetooth看驱动 / 固件是否报错。系统崩溃 / 重启看崩溃前内核打印的错误信息。固件缺失比如dmesg提示Direct firmware load failed→ 说明缺少对应硬件的固件文件。 与其他日志工具的区别工具来源用途dmesg内核环形缓冲区内核 / 硬件 / 驱动层调试journalctlsystemd-journald系统 / 服务 / 应用层日志包含内核日志tail -f /var/log/...应用日志文件特定应用的业务日志 一句话总结dmesg就是内核的 “黑匣子”所有和硬件、驱动相关的问题都要先从dmesg开始查。tailtail和cat有啥区别我用最简单、最直观、一看就懂的方式给你讲清楚一句话区别cat 一次性把文件全部显示出来tail 只显示文件最后几行还能实时追新加的内容1. cat 命令作用把整个文件从头到尾全部打印出来cat app.log特点全部输出不能实时追新日志文件太大时会刷屏根本看不完适合看小文件、看配置文件2. tail 命令作用只看文件最后几行还能实时跟踪新内容tail app.log # 只看最后10行 tail -n 20 app.log # 看最后20行 tail -f app.log # 实时追新日志调试神器特点只看末尾-f 可以实时刷新新日志不会刷屏适合看日志适合看运行日志、调试程序、实时输出最直观的比喻cat 把整本书一页不差全部读给你听tail 只读最后几页而且新书一出来马上读给你听你调试蓝牙 / 程序应该用哪个一定用 tail -ftail -f /var/log/app.log因为程序运行时日志一直在增加只有tail -f能实时看到最新打印。超级总结cat看全部静态不适合日志tail看末尾-f 实时跟踪调试必用tail -F是什么tail -F是tail命令的增强版专门用于日志文件被轮转 / 重建时仍能持续跟踪比-f更健壮。 与tail -f的核心区别命令行为适用场景tail -f跟踪当前打开的文件描述符如果文件被删除 / 重命名 / 重建会停止更新临时调试、文件不会被轮转的场景tail -F跟踪文件名会定期检查文件是否存在 / 变更文件重建后自动重新打开生产环境、日志轮转logrotate的长期监控简单说-f认 “文件句柄”文件没了就停-F认 “文件名”文件删了重建还能继续追 常用用法# 实时跟踪日志不怕日志被切割/重建 tail -F /var/log/ask_wifi_manager.log # 结合 grep 过滤关键日志 tail -F /var/log/app.log | grep error # 显示最后 50 行并实时跟踪 tail -n 50 -F /var/log/app.log 典型场景日志轮转logrotate系统会定期把旧日志改名如app.log → app.log.1并新建app.logtail -F会自动切换到新文件。应用重启重建日志应用重启时会清空 / 重建日志文件tail -F不会中断。长期监控比-f更稳定适合长时间跑监控脚本。⚠️ 注意事项tail -F本质是--followname --retry的组合会有短暂的轮询延迟默认 1 秒。如果文件被删除且长时间未重建tail -F会持续等待直到文件再次出现。调试时临时看日志用-f足够长期监控推荐用-F。✅ 一句话总结tail -F 不怕日志文件被删 / 改名 / 重建的 “不死版” 实时日志跟踪是生产环境调试的首选。