常见问题与解决方法

问题1：使用systemctl和top命令查询libvirtd服务占用内存不同

问题描述

使用systemctl和systemd-cgtop命令查询libvirtd服务占用内存超1.5G，而使用top命令查询libvirtd服务占用内存仅70M左右。

原因分析

systemd管理的服务（包括systemctl和systemd-cgtop）中显示的内存通过查询CGroup对应的memory.usage_in_bytes得到。top是直接统计/proc下内存相关信息计算得出。两者的统计方法不同，不能直接比较。

一般来说，业务进程使用的内存主要有以下几种情况：

• anon_rss：用户空间的匿名映射页（Anonymous pages in User Mode address spaces），比如调用malloc分配的内存，以及使用MAP_ANONYMOUS的mmap。当系统内存不够时，内核可以将这部分内存交换出去。
• file_rss：用户空间的文件映射页（Mapped pages in User Mode address spaces），包含map file和map tmpfs，前者比如指定文件的mmap，后者比如IPC共享内存。当系统内存不够时，内核可以回收这些页，但回收之前可能需要与文件同步数据。
• file_cache：文件缓存（page in page cache of disk file），普通读写（read/write）文件时产生的文件缓存。当系统内存不够时，内核可以回收这些页，但回收之前可能需要与文件同步数据。
• buffer pages：属于page cache，比如读取块设备文件时的相关缓存。

其中anon_rss和file_rss属于进程的RSS，file_cache和buffer pages属于page cache。简单来说：

top里的RSS = anon_rss + file_rss，SHR = file_rss。

CGroup里的memory.usage_in_bytes = cache + RSS + swap。

由上可知，syestemd相关命令和top命令的内存占用率含义不同，所以查询结果不同。

问题2：设置RAID0卷，参数stripsize设置为4时出错

问题现象

设置RAID0卷，参数stripsize设置为4时出错。

原因分析

64K页表开启只能支持64K场景。

解决方法

不需要修改配置文件，openEuler执行lvcreate命令时，条带化规格支持的stripesize最小值为64KB，将参数stripesize设置为64。

问题3：使用rpmbuild编译mariadb失败

问题描述

如果使用root帐号登录系统，并在该帐号下使用rpmbuild命令编译mariadb源代码，会出现编译失败现象，提示：

# echo 'mysql can'\''t run test as root'
mysql can't run test as root
# exit 1

原因分析

mariadb数据库不允许使用root权限的帐号进行测试用例执行，所以会阻止编译过程（编译过程中会自动执行测试用例）。

解决方案

使用vi等文本编辑工具，修改mariadb.spec文件中runtest变量的值。

修改前：

%global runtest 1

修改后：

%global runtest 0

该修改关闭了编译阶段执行测试用例的功能，但不会影响编译和编译后的RPM包内容。

问题4：使用默认配置启动SNTP服务失败

问题现象

默认配置情况下SNTP服务启动失败。

原因分析

默认配置中未添加授时服务器域名。

解决方案

修改/etc/sysconfig/sntp文件 ，在文件中添加中国NTP快速授时服务器域名：0.generic.pool.ntp.org。

问题5：安装时出现软件包冲突、文件冲突或缺少软件包导致安装失败

问题现象

安装软件包过程中，可能出现软件包冲突、文件冲突或缺少软件包，从而导致升安装被中断，最终安装失败。软件包冲突、文件冲突和缺少软件包的报错信息分别如下所示。

软件包冲突报错信息示例（以 libev-libevent-devel-4.24-11.oe1.aarch64与libevent-devel-2.1.11-2.oe1.aarch64冲突为例）：

package libev-libevent-devel-4.24-11.oe1.aarch64 conflicts with libevent-devel provided by libevent-devel-2.1.11-2.oe1.aarch64  
 - cannot install the best candidate for the job  
 - conflicting requests

文件冲突报错信息示例（以/usr/bin/containerd文件冲突为例）：

Error: Transaction test error:  
 file /usr/bin/containerd from install of containerd-1.2.0-101.oe1.aarch64 conflicts with file from package docker-engine-18.09.0-100.aarch64  
 file /usr/bin/containerd-shim from install of containerd-1.2.0-101.oe1.aarch64 conflicts with file from package docker-engine-18.09.0-100.aarch64

缺少软件包的报错信息示例（以缺失blivet-data软件包为例）：

Error:  
  Problem: cannot install both blivet-data-1:3.1.1-6.oe1.noarch and blivet-data-1:3.1.1-5.noarch  
   - package python2-blivet-1:3.1.1-5.noarch requires blivet-data = 1:3.1.1-5, but none of the providers can be installed  
   - cannot install the best update candidate for package blivet-data-1:3.1.1-5.noarch  
   - problem with installed package python2-blivet-1:3.1.1-5.noarch(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

原因分析

• openEuler提供的软件包中，有些软件包虽然名称不同，但功能相同，导致两个软件包无法同时安装。
• openEuler提供的软件包中，有些软件包虽然名称不同，但功能相同，导致安装时安装后的文件相同，从而产生了文件冲突。
• 有些软件包，因在升级安装前被其他软件包所依赖，一旦该软件包升级后，可能导致依赖它的软件包因缺少软件包而不能安装。

解决方案

若为软件包冲突，则按如下步骤进行处理（以问题现象中示例的软件包冲突为例）：

1. 根据安装过程中的软件包冲突报错信息，确定与待安装的 libev-libevent-devel-4.24-11.oe1.aarch64软件包冲突的软件包为libevent-devel-2.1.11-2.oe1.aarch64。

2. 执行dnf remove命令将与待安装软件包冲突的软件包单独卸载。

   # dnf remove libevent-devel-2.1.11-2.oe1.aarch64
   

3. 重新进行安装操作。

若为文件冲突，则按如下步骤进行处理（以问题现象中示例的文件冲突为例）：

1. 根据安装过程中的文件冲突报错信息，确定导致文件冲突的软件包名称为containerd-1.2.0-101.oe1.aarch64和docker-engine-18.09.0-100.aarch64。

2. 将不需要安装的软件包名称记录下来，以不需要安装docker-engine-18.09.0-100.aarch64为例。

3. 执行dnf remove命令将不需要安装的软件包单独卸载。

   # dnf remove docker-engine-18.09.0-100.aarch64
   

4. 重新进行安装操作。

若为缺少软件包，则按如下步骤进行处理（以问题现象中示例的缺少软件包为例）：

1. 根据升级安装过程中的缺少软件包报错信息，确定待升级的软件包名称blivet-data-1:3.1.1-5.noarch及依赖它的软件包名称python2-blivet-1:3.1.1-5.noarch。

2. 执行dnf remove命令将依赖待升级包才能安装的软件包单独卸载或在升级软件包时加上--allowerasing参数。

   • 执行dnf remove命令将依赖blivet-data-1:3.1.1-5.noarch软件包才能安装的软件包单独卸载。

     # dnf remove python2-blivet-1:3.1.1-5.noarch
     

   • 升级软件包时加上--allowerasing参数。

     # yum update blivet-data-1:3.1.1-5.noarch -y --allowerasing
     

3. 重新进行升级操作。

安装冲突实例

• 文件冲突

  python3-edk2-devel.noarch 与 build.noarch 因文件名重复存在冲突。

  # yum install python3-edk2-devel.noarch build.noarch
  ...
  Error: Transaction test error:
  file /usr/bin/build conflicts between attempted installs of python3-edk2-devel-202002-3.oe1.noarch and build-20191114-324.4.oe1.noarch
  

问题6：libiscsi降级失败

问题现象

libiscsi-1.19.0-4 版本及以上降级到 libiscsi-1.19.0-3 及以下版本时失败。

Error:
Problem: problem with installed package libiscsi-utils-1.19.0-4.oe1.x86_64
- package libiscsi-utils-1.19.0-4.oe1.x86_64 requires libiscsi(x86-64) = 1.19.0-4.oe1, but none of the providers can be installed
- cannot install both libiscsi-1.19.0-3.oe1.x86_64 and libiscsi-1.19.0-4.oe1.x86_64
- cannot install both libiscsi-1.19.0-4.oe1.x86_64 and libiscsi-1.19.0-3.oe1.x86_64
- conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

原因分析

libiscsi-1.19.0-3 之前的版本把 iscsi-xxx 等二进制文件打包进了主包 libiscsi，而这些二进制文件引入了不合理的依赖 CUnit, 为了解决这种不合理的依赖，在 libiscsi-1.19.0-4 版本把这些二进制文件单独拆分出来一个子包 libiscsi-utils，主包弱依赖于子包，产品可以根据自己的需求在做镜像时是否集成该子包；不集成或卸载子包不会影响 libiscsi 主包的功能。 如果系统中安装了 libiscsi-utils 子包，libiscsi-1.19.0-4 及以上版本降级到 libiscsi-1.19.0-3 及以下版本时，由于 libiscsi-1.19.0-3 及以下版本无法提供对应的 libiscsi-utils，因此 libiscsi-utils 不会降级，但 libiscsi-utils 依赖于降级前的 libiscsi 主包，导致依赖问题无法解决，最终导致降级失败。

解决方案

执行以下命令，卸载 libiscsi-utils 子包，卸载成功后再进行降级操作。

yum remove libiscsi-utils

问题7：xfsprogs降级失败

问题现象

xfsprogs-5.6.0-2 及以上版本降级到 xfsprogs-5.6.0-1 及以下版本时失败。

Error:
Problem: problem with installed package xfsprogs-xfs_scrub-5.6.0-2.oe1.x86_64
- package xfsprogs-xfs_scrub-5.6.0-2.oe1.x86_64 requires xfsprogs = 5.6.0-2.oe1, but none of the providers can be installed
- cannot install both xfsprogs-5.6.0-1.oe1.x86_64 and xfsprogs-5.6.0-2.oe1.x86_64
- cannot install both xfsprogs-5.6.0-2.oe1.x86_64 and xfsprogs-5.6.0-1.oe1.x86_64
- conflicting requests

原因分析

在 xfsprogs-5.6.0-2 版本中，为了减少 xfsprogs 主包的不合理依赖，同时将实验性质的命令从主包中分来，我们将 xfs_scrub* 命令拆分到单独的 xfsprogs-xfs_scrub 子包中。而 xfsprogs 主包弱依赖于 xfsprogs-xfs_scrub 子包，所以产品可以根据自己的需求在做镜像时是否集成该子包，或者是否卸载该子包。不集成或卸载该子包不会影响 xfsprogs 主包功能。

如果系统中安装了 xfsprogs-xfs_scrub 子包，从 xfsprogs-5.6.0-2 及以上版本降级到 xfsprogs-5.6.0-1 及以下版本时，由于 xfsprogs-5.6.0-1 及以下版本无法提供对应的 xfsprogs-xfs_scrub，因此 xfsprogs-xfs_scrub 不会降级，但 xfsprogs-xfs_scrub 依赖于降级前的 xfsprogs 主包，导致依赖问题无法解决，最终导致降级失败。

解决方案

执行以下命令，卸载 xfsprogs-xfs_scrub 子包，卸载成功后再进行降级操作。

# yum remove xfsprogs-xfs_scrub

问题8：cpython/Lib发现CVE-2019-9674:Zip炸弹漏洞

问题现象

Python 3.7.2 及以下版本中的 Lib/zipfile.py 允许远程攻击者通过 zip 炸弹制造拒绝服务请求，从而导致资源消耗过大。

原因分析

远程攻击者通过 zip 炸弹导致拒绝服务，影响目标系统业务甚至达到使系统崩溃的结果。zip 炸弹就是一个高压缩比的 zip 文件，它本身可能只有几M或几十M的大小，但是解压缩之后会产生巨大的数据量，产生巨大的资源消耗。

解决方案

在 zipfile 文档中添加告警信息： https://github.com/python/cpython/blob/3.7/Doc/library/zipfile.rst。

问题9：不合理使用glibc正则表达式引起ReDoS攻击

问题现象

使用glibc的regcomp/regexec接口编程，或者grep/sed等应用glibc正则表达式的shell命令，不合理的正则表达式或输入会造成ReDoS攻击（CVE-2019-9192/CVE-2018-28796）。 典型正则表达式pattern为“反向引用”（\1表示）与“*”（匹配零次或多次）、“+”（匹配一次或多次）、“{m,n}”（最小匹配m次，最多匹配n次）的组合，或者配合超长字符串输入，示例如下：

# echo D | grep -E "$(printf '(\0|)(\\1\\1)*')"Segmentation fault (core dumped)
# grep -E "$(printf '(|)(\\1\\1)*')"
Segmentation fault (core dumped)
# echo A | sed '/\(\)\(\1\1\)*/p'
Segmentation fault (core dumped)
# time python -c 'print "a"*40000' | grep -E "a{1,32767}"
Segmentation fault (core dumped)
# time python -c 'print "a"*40900' | grep -E "(a)\\1"
Segmentation fault (core dumped)

原因分析

使用正则表达式的进程coredump。具体原因为glibc正则表达式的实现为NFA/DFA混合算法，内部原理是使用贪婪算法进行递归查找，目的是尽可能匹配更多的字符串，贪婪算法在处理递归正则表达式时会导致ReDoS。

解决方案

1. 需要对用户做严格的权限控制，减少攻击面。

2. 用户需保证正则表达式的正确性，不输入无效正则表达式，或者超长字符串配合正则的“引用” “*”等容易触发无限递归的组合。

   # ()(\1\1)*
   # "a"*400000
   

3. 用户程序在检测到进程异常之后，通过重启进程等手段恢复业务，提升程序的可靠性。

问题10：安装卸载httpd-devel和apr-util-devel软件包，其中的依赖包gdbm-devel安装、卸载有报错

问题现象

1. gdbm-devel-1.18.1-1包安装、卸载有报错；
2. 问题1修复后，gdbm和gdbm-devel包更新到1.18.1-2版本，但在安装httpd-devel、apr-util-devel等包（依赖关系中有gdbm-devel软件包）时，默认安装的gdbm-devel还是1.18.1-1旧版本，导致问题报错依然存在。

原因分析

1. gdbm-devel-1.18.1-1包中缺少提供info信息的help软件包，导致单独安装gdbm-devel并不能将help包引入进来，所以出现了如下告警信息。

   install-info: 没有那个文件或目录 for /usr/share/info/gdbm.info.gz
   

2. 由于系统默认安装的gdbm主包是1.18.1-1版本，而没有安装gdbm-devel包。依赖gdbm-devel包的相关软件包在安装gdbm-devel包的过程中，仍会匹配gdbm的主包版本，故而依然安装了gdbm-devel的旧版本1.18.1-1,导致警告信息依然存在。

解决方案

1. 单包升级gdbm，安装使用gdbm-1.18.1-2版本相关软件包后，告警信息消失；
2. 在单包升级gdbm后，再进行安装依赖的gdbm-devel软件包安装，让其依赖高版本gdbm软件包，告警信息消失。

问题11：系统reboot后，执行yum/dnf等命令报错，提示rpmdb error

问题现象

1. reboot系统，重启后，执行rpm相关命令(yum/dnf)提示：
   error: db5 error(-30973) from dbenv->open: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
   error: cannot open Packages index using db5 - (-30973)
   error: cannot open Packages database in /var/lib/rpm
   Error: Error: rpmdb open failed

原因分析

1. 执行安装升级动作过程中，会对/var/lib/rpm/__db.00*文件进行读写操作，如果在运行中出现强制下电、磁盘空间满或者 ‘kill -9’ 等异常中断操作，会导致对应_db文件损坏，后续执行rpm相关命令（dnf/yum）会发生报错

解决方案

步骤1 执行kill -9停止所有正在运行的rpm命令。 步骤2 执行rm -rf /var/lib/rpm/__db.00*删除所有db.00的文件。 步骤3 执行rpmdb --rebuilddb命令，重建rpm db后即可。

问题12：执行 rpmrebuild -d /home/test filesystem对filesystem包rebuild时，rebuild失败

问题现象

执行 rpmrebuild --comment-missing=y --keep-perm -b -d /home/test filesystem-3.16-3.oe1.aarch64对filesystem包rebuild时，rebuild失败. /usr/lib/rpmrebuild/rpmrebuild.sh:Error:(RpmBuild) Package 'filesystem-3.16-3.oe1.aarch64' build failed. /usr/lib/rpmrebuild/rpmrebuild.sh:Error: RpmBuild

原因分析

软件包在%pretrans -p阶段创建目录，并在%ghost阶段对该目录进行修饰，如果用户在该目录下创建目录或文件，执行rpmrebuild对该包进行打包，发现创建的目录或文件也会打包到该包中。

上述问题的根本原因是因为filesystem在%pretrans阶段创建了/proc目录，并在%ghost阶段对该目录进行了修饰，但是该目录在系统运行时会动态的创建一些微量进程，这些进程非目录也非文件，在执行rpmrebuild的时无法对这些进程进行打包，所以rebuild失败。

解决方案

暂时不使用rpmrebuild命令对filesystem进行rebuild。

问题13：带参数f执行modprobe或insmod报错

问题现象

执行modprobe -f <mod>或insmod -f <mod>.ko.xz报错，比如insmod -f xfs.ko.xz报错：modprobe: ERROR: could not insert 'xfs': Key was rejected by service。

迄今为止(2022.09.20, kmod v30)，该问题尚未被kmod社区修复。Linux v5.17 b1ae6dc添加了对压缩内核模块的支持，kmod尚未支持该特性。

原因分析

对于未经压缩的ko，{modprobe, insmod}使用finit_module()系统调用，而对于压缩的ko，解压由kmod完成，使用init_module()系统调用。系统调用init_module()无法传入ignore check的flag，导致内核执行路径中mod_verify_sig()始终进入，并且{modprobe, insmod} -f参数会更改ko有关的校验信息，导致mod_verify_sig()校验失败。

解决方案

对压缩了的ko不使用{insmod, modprobe} -f。