[内容] Linux console 口输出信息简介

正文:

内容一:Linux console 口输出信息的案例

......
[233901.562021] systemd[1]: Failed to start Journal Service.
[234212.762021] systemd[1]: Failed to start Journal Service.
[234477.728002] systemd[1]: Failed to start Journal Service.
[234599.842019] systemd[1]: Failed to start Journal Service.
[235000.845000] systemd[1]: Failed to start Journal Service.
......

内容二:Linux console 口输出信息的性质

Linux console 口的输出信息不存储在系统日志里,而是在 Linux 内存,重启后则清除

内容三:Linux console 口输出信息的内容

3.1 输出信息的时间部分

其中 [235000.845000] 是自上次开机以后系统运行的秒数

3.2 输出信息的内容部分

systemd[1]: Failed to start Journal Service. 是输出信息的内容

补充:

[排错] 解决 Linux 启动时某些服务没有开机自启 (日志里报错: “deleted to break ordering cycle starting”)

报错代码

某些服务没有开机自启例如 NetworkManager.service

原因分析

在系统日志里可以类似 …… Job network.target/start deleted to break ordering cycle starting with …… 报错例如:

# cat /var/log/messages
Jan 1 10:09:24 server systemd[1]: network-online.target: Found ordering cycle on network.target/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on NetworkManager.service/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on basic.target/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on slices.target/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on mysql.slice/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on remote-fs.target/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on remote-fs-pre.target/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on iscsi.service/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Found dependency on network-online.target/start
Jan 1 10:09:24 server systemd[1]: network-online.target: Job network.target/start deleted to break ordering cycle starting with network-online.target/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found ordering cycle on NetworkManager.service/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on basic.target/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on slices.target/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on mysql.slice/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on remote-fs.target/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on remote-fs-pre.target/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on iscsi.service/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on network-online.target/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Found dependency on NetworkManager-wait-online.service/start
Jan 1 10:09:24 server systemd[1]: NetworkManager-wait-online.service: Job NetworkManager.service/start deleted to break ordering cycle starting with NetworkManager-wait-online.service/start

从案例中日志里的内容可以判断:
1) network.target/NetworkManager.service 启动
2) NetworkManager.service 作为基础服务依赖 basic.target
3) basic.target 依赖所有 slice 包括 mysql.slice
4) mysql.slice 依赖 iscsi.service/remote-fs.target/remote-fs-pre.target
5) iscsi.service/remote-fs.target/remote-fs-pre.target 依赖 network.target/NetworkManager.service
6) 系统为了防止启动时陷入死循环,systemd 报错 Job NetworkManager.service/start deleted to break ordering cycle 并放弃启动 NetworkManager.service

解决方法

取消不太重要的服务的依赖要求

# vi /etc/systemd/system/mysql.slice

将以下内容:

......
Before=slices.target
Wants=-.slice
After=-.slice remote-fs.target
......

修改为:

......
Before=slices.target
Wants=-.slice
After=-.slice remote-fs.target
......

(补充:这里以取消使用 /etc/systemd/system/mysql.slice 文件的服务的依赖要求为例)

[排错] 解决 Linux 开机时报错 “kernel panic – no syncing: Attempted to kill init ……”

报错代码

/init: error while loading shared libraries: libsystemd-shared-239.so: cannot open shared object file: No such file or directory
kernel panic - no syncing: Attempted to kill init! exitcode=0x00007f00

解决方法

步骤一:进入拯救模式

步骤二:确认第三方软件库

2.1 搜集第三方软件库信息

# ldconfig -p > /tmp/ldconfig.out

2.2 确认有没有第三方软件库

# for l in $(awk '{ print $1 }' /tmp/ldconfig.out); do matches=$(awk "\$1 == \"$l\" { print }" /tmp/ldconfig.out); if [ $(echo "$matches" | wc -l) -ge 2 ]; then echo "$matches"; echo; fi; done

(补充:如果没有第三方软件库的话这里不会有任何输出)

步骤三:检查 /etc/ld.so.conf 文件或者 /etc/ld.so.conf.d/ 目录里的文件去除第三方库

(步骤略)

步骤四:刷新库缓存

# ldconfig

步骤五:为启动失败的系统创建创建 initramfs 文件

# dracut -f /boot/initramfs-(uname -r).img $(uname -r)

(补充:这里以将正在运行的内核版本生成一个新的 initramfs 为例)

(注意:此时原来启动系统时使用的那个 initramfs 文件会被覆盖)

步骤六:重启系统

# reboot

参考文献

https://access.redhat.com/solutions/7096246

[步骤] Linux 第三方库的添加

步骤一:添加第三方库

# vi /etc/ld.so.conf

或者:

# vi /etc/ld.so.conf.d/*.conf

添加以下内容:

......
/root/lib

(补充:这里以添加位于目录 /root/lib 的库为例)

(注意:这里的 /etc/ld.so.conf.d/*.conf 是指 /etc/ld.so.conf.d/ 目录下任意以 .conf 结尾的文件,例如 /etc/ld.so.conf.d/one.conf)

步骤二:创建新的 initramfs 文件为例

2.1 备份已有的 initramfs 文件

# cp /boot/initramfs-4.18.0-553.89.1.el8_10.x86_64.img  /boot/initramfs-4.18.0-553.89.1.el8_10.x86_64.img.backup


补充:
1) 这里以将:/boot/initramfs-4.18.0-553.89.1.el8_10.x86_64.img 备份为:/boot/initramfs-4.18.0-553.89.1.el8_10.x86_64.img.backup 为例
2) initramfs 是压缩的 cpis 文件,是临时的根文件系统包含一些脚本、程序和配置文件,在 Linux 启动过程中被加载在内存里,负责 Linux 操作系统在挂载根目录前加载内核模块、检查硬件、加载驱动以及挂载真正的根文件系统等)

2.2 创建新的 initramfs 文件

# dracut -f /boot/initramfs-(uname -r).img $(uname -r)

(补充:这里以将正在运行的内核版本生成一个新的 initramfs 为例)

(注意:此时原来启动系统时使用的那个 initramfs 文件会被覆盖)

步骤三:重启系统

# reboot

步骤四:确认第三方库已经添加

4.1 确认在现在的缓存中包含了第三方库

# ldconfig -p -M -X | grep out


补充:
1) 这里的 -N 和 -X 必须一起使用,作用是不更新相关链接和不重建相关缓存
2) 这里的 -p 作用是打印现在在缓存中的相关目录和相关候选库
3) 这条命令会显示目前在缓存中的第三方库

4.2 确认加载的库中没有重复的

# for l in $(ldconfig -p -N -X | awk '{ print $1 }') ; do matches=$(ldconfig -p -N -X | awk "\$1 == \"$l\" { print }"); if [ $(echo "$matches" | wc -l) -ge 2 ]; then echo "$matches"; echo; fi; done |wc -l

(补充:如果加载的库中没有重复的则这里不会有任何输出结果)

[内容] 两台 Linux MAC 地址冲突后的出现的现象 (两台 Linux 系统在同 1 个二层交换机下使用相同的 MAC 地址)

现象一:ping 命令会卡住

ping MAC 地址冲突的 Linux IP 地址时,ping 的延迟不高,但是 ping 命令会随机卡住

现象二:SSH 远程登录后输入命令会卡住

通过 SSH 登录 MAC 地址冲突的 Linux IP 地址时,可以正常登录,但是输入命令后会随机卡住

现象三:SNMP 客户端失效

此时 MAC 地址冲突的 Linux SNMP 客户端无法被其他机器发现。若此时通过 SNMPv3 访问此 Linux 的 SNMP 客户端,验证可以通过,但是无法拉取信息