我正在编写一个显示各种系统信息的程序(在 CentOS 系统上)。例如,处理器类型和速度(来自/proc/cpuinfo
)、上次启动时间(根据 计算/proc/uptime
)、IP 地址(来自ifconfig
输出)以及已安装打印机的列表(来自lpstat
输出)。
目前,从程序中得到几条数据dmidecode
:
- 平台类型 (
dmidecode -s system-product-name
) - BIOS 版本 (
dmidecode -s bios-version
) - 物理内存大小 (
dmidecode -t17 | grep Size
)
仅当我的程序以 root 身份运行时,这些才可用(因为否则dmidecode
子进程会因错误而失败/dev/mem: Permission denied
)。是否有普通用户可以访问的替代方法来获取此信息?
答案1
提供的一些信息dmidecode
可在 处获得/sys/devices/virtual/dmi/id
。
其他信息可以通过分析获得/proc/cpuinfo
,/proc/meminfo
或者/sys/system/node/node0/meminfo
。
答案2
我可以作为用户读取 DMI 信息
/sys/class/dmi/id/
。不包括序列号(需要 root 权限才能读取)。我想这是具有隐私意识的内核开发人员的预期行为。
关于
dmesg
:dmesg
是访问内核环形缓冲区的命令。环形缓冲区意味着当缓冲区“溢出”时,较旧的信息将被较新的信息覆盖。此外,这是读取内核模块调试输出,该输出从来都不是可解析的。要使用
systemd
运行访问内核输出:journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
关于大卫·荷马的和尼尔斯解答:该文件
/dev/mem
并不简单地给出内存信息,而是将整个物理内存映射到用户空间。因此,人们可以通过它访问 DMI 内存地址(并做更多令人讨厌的事情)。关于
chgrp
和chmod g+s
的dmidecode
尼尔斯回答:我想这不会按预期工作,因为保存 gid withchmod g+s
不会dmidecode
使用它的新权限。dmidecode
必须先调用setegid
设置其有效组 ID,然后才能访问/dev/mem
.从它的源代码来看,dmidecode
并没有这样做。
答案3
我刚刚检查了我的 CentOS 5 系统 - 之后:
chgrp kmem /usr/sbin/dmidecode
chmod g+s /usr/sbin/dmidecode
仍然无法让 dmidecode 工作 - kmem 组只有 /dev/mem 的读取权限 - 似乎涉及到 BIOS 信息的写入。
所以还有一些其他选择:
- 使用须藤
- 使用其他信息源(例如 /proc/meminfo )
- 使用 init 脚本将 dmidecode 的静态输出写入世界可读的文件
答案4
我不确定为什么@mtneagle 被否决了。
OP 想要的三个项目是:
平台类型 ( dmidecode -s system-product-name
)
BIOS 版本 ( dmidecode -s bios-version
)
物理内存量 ( dmidecode -t17 | grep Size
)
我们可以这样得到每一个:
dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "1"
dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "2"
dmesg | grep "Memory:" | cut -d '/' -f '2-' | cut -d ' ' -f '1'
(或者至少这些工作在我拥有的 4 个不同的硬件服务器上,并且在 Xen 来宾上完全没有返回任何 BIOS 或服务器类型。)
我错过了一些明显的事情吗?
更新:感谢@Ruslan 指出了我错过的明显内容。
引用:
是的,你有。内核消息存储在环形缓冲区中。当打印太多行时,第一行将被删除。
因此,如果您的计算机已经工作了数周,并且您至少每天都暂停/恢复它,则很有可能您在此处 grep 的信息将不再位于缓冲区中。
(我这里有这样的情况,正常运行时间为 18 天。)最好检查一下
/var/log/kern.log
就像是
grep DMI: /var/log/kern.log | tail -n1