Почему использование памяти службой libvirtd разное при запросе командами systemctl и top?#

Симптом#

В выходных данных команд systemctl и systemd-cgtop показано, что сервис libvirtd занимает более 1,5 ГБ памяти, а в выводе команды top — что он занимает около 70 МБ.

Возможная причина#

Отображаемая память для сервисов (включая systemctl и systemd-cgtop), управляемых systemd, может быть получена из memory.usage_in_bytes в Cgroup. Команда top запрашивает сведения о памяти в каталоге /proc. Результаты запроса отличаются из-за использования другого статистического метода.

Как правило, память, используемая сервисными процессами, бывает следующих типов.

• anon_rss: анонимные страницы в адресных пространствах пользовательского режима, например память, выделяемая вызовом malloc или функции mmap с флагом MAP_ANONYMOUS. Когда системной памяти недостаточно, ядро может выделять подкачку для памяти этого типа.
• file_rss: страницы отображения в адресных пространствах пользовательского режима, включая файл отображения (например, mmap указанного файла) и tmpfs отображения (например, разделяемая память IPC). Когда системной памяти недостаточно, ядро может высвобождать эти страницы. Перед высвобождением может потребоваться синхронизировать данные между ядром и файлом отображения.
• file_cache: файловый кэш (страница в страничном кэше дискового файла), который генерируется при чтении или записи файла. Когда системной памяти недостаточно, ядро может высвобождать эти страницы. Перед высвобождением может потребоваться синхронизировать данные между ядром и файлом отображения.
• Страницы буфера: принадлежат страничному кэшу, например создаваемому при чтении файлов блочного устройства.

Память anon_rss и file_rss относится к резидентному набору (RSS) процессов, а file_cache и страницы буфера — к страничному кэшу. Вкратце:

RSS в выводе команды top = anon_rss + file_rss; разделяемая память (SHR) = file_rss

memory.usage_in_bytes в Cgroup = кэш + RSS + подкачка

В заключение отметим, что определение использования памяти, получаемого командой systemd, отличается от определения использования, получаемого top. Поэтому отличаются и результаты запросов.

Ошибка при настройке тома RAID 0, если stripsize имеет значение 4#

Симптом#

Когда для параметра stripsize установлено значение 4 при настройке тома RAID 0, возникает ошибка.

Возможная причина#

Таблицу страниц размером 64 КБ можно включить только в сценарии, когда для stripsize задано значение 64.

Решение#

Изменять файл конфигурации не требуется. При запуске в Скейлер команды lvcreate установите для stripsize значение 64, поскольку минимальный поддерживаемый размер страйпа — 64 КБ.

Сбой компиляции MariaDB с использованием rpmbuild#

Симптом#

При входе в систему в роли пользователя root и компиляции исходного кода MariaDB с помощью команды rpmbuild компиляция завершается сбоем и отображаются следующие сведения:

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

Возможная причина#

MariaDB не позволяет пользователю root выполнять тестовые случаи. Однако при компиляции тестовые случаи выполняются автоматически. В результате процесс компиляции блокируется.

Решение#

Используйте текстовый редактор, например vi, и измените значение переменной runtest в файле mariadb.spec.

Перед изменением:

%global runtest 1

После изменения:

%global runtest 0

Это изменение отключает функцию выполнения тестовых случаев в ходе компиляции, что никак не повлияет на компиляцию и содержимое пакета RPM после ее завершения.

Сбой запуска сервиса SNTP с использованием конфигурации по умолчанию#

Симптом#

Сервис SNTP не запускается с конфигурацией по умолчанию.

Возможная причина#

В конфигурацию по умолчанию не добавлено доменное имя NTP-сервера.

Решение#

Отредактируйте файл /etc/sysconfig/sntp и добавьте доменное имя сервера NTP в Китае: 0.generic.pool.ntp.org.

Сбой установки из-за конфликта файлов или пакетов ПО либо отсутствия пакета ПО#

Симптом#

При установке пакета программного обеспечения возникает конфликт пакетов ПО, конфликт файлов или отсутствие каких-то пакетов ПО. В результате обновление прерывается, а установка завершается сбоем. Сведения об ошибке в связи с конфликтом пакетов ПО или файлов либо с отсутствием пакетов ПО выглядят, как показано ниже.

Пример сведений об ошибке из-за конфликта между пакетами ПО 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)

Возможная причина#

• Некоторые пакеты программного обеспечения, предоставляемые Скейлер, имеют разные имена, но одинаковые функции. Из-за этого такие пакеты не могут быть установлены одновременно.
• Некоторые пакеты программного обеспечения, предоставляемые Скейлер, имеют разные имена, но одинаковые функции. Из-за этого файлы после установки одинаковые, что приводит к конфликту файлов.
• Перед обновлением у некоторых пакетов ПО были другие зависимые от них пакеты. После обновления пакетов зависящие от них пакеты могут не устанавливаться по причине отсутствия нужных пакетов.

Решение#

Если возникает конфликт пакетов ПО, выполните следующие действия (для примера используется конфликт пакетов из раздела “Симптом”).

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.

   • Чтобы удалить пакет ПО, зависящий от пакета blivet-data-1:3.1.1-5.noarch, выполните следующую команду dnf remove.

     # 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
  

Сбой перехода на более раннюю версию libiscsi#

Симптом#

Невозможно перейти с libiscsi-1.19.4 или более поздней версии на libiscsi-1.19.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.3 и более ранних версиях двоичные файлы с именами iscsi-xxx входят в основной пакет libiscsi. Однако эти двоичные файлы вводят некорректную зависимость CUnit. Для решения этой проблемы в libiscsi-1.19.4 эти файлы выделены в подпакет libiscsi-utils. Основной пакет имеет слабую зависимость от подпакета. Вы можете интегрировать или удалить подпакет при создании образа в зависимости от требований продукта. Если подпакет не интегрирован или удален, это никак не затрагивает функции основного пакета libiscsi. Если осуществляется переход с libiscsi-1.19.4 или более поздней версии на libiscsi-1.19.3 или более раннюю версию и в системе установлен подпакет libiscsi-utils, то, поскольку libiscsi-1.19.3 и более ранние версии не содержат libiscsi-utils, перейти на более раннюю версию libiscsi-utils не удастся. Из-за того, что libiscsi-utils имеет зависимость от основного пакета libiscsi до перехода на более раннюю версию, возникает проблема с зависимостью и переход на более раннюю версию libiscsi завершается сбоем.

Решение#

Удалите подпакет libiscsi-utils, выполнив следующую команду, и лишь затем перейдите на более раннюю версию:

yum remove libiscsi-utils

Сбой перехода на более раннюю версию 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-5.6.0-2 или более поздней версии на xfsprogs-5.6.0-1 или более раннюю версию и в системе установлен подпакетxfsprogs-xfs_scrub, то, поскольку xfsprogs-5.6.0-1 и более ранние версии не содержат xfsprogs-xfs_scrub, перейти на более раннюю версию xfsprogs-xfs_scrub не удастся. Из-за того, что xfsprogs-xfs_scrub имеет зависимость от основного пакета xfsprogs до перехода на более раннюю версию, возникает проблема с зависимостью и переход на более раннюю версию libiscsi завершается сбоем.

Решение#

Удалите подпакет xfsprogs-xfs_scrub, выполнив следующую команду, и лишь затем перейдите на более раннюю версию:

yum remove xfsprogs-xfs_scrub

CPython/Lib обнаруживает уязвимость CVE-2019-9674: ZIP-бомба#

Симптом#

Lib/zipfile.py в Python 3.7.2 и более ранних версиях позволяет удаленным злоумышленникам создавать DoS-запросы с использованием ZIP-бомб, вызывая высокое потребление ресурсов.

Возможная причина#

Удаленные злоумышленники используют ZIP-бомбы с целью вызова отказов в обслуживании (DoS), затрагивающих целевые системные сервисы или даже приводящих к сбою системы. ZIP-бомба — это ZIP-файл с высокой степенью сжатия размером от нескольких до десятков мегабайт. Однако при его распаковке генерируется большой объем данных, что приводит к высокому потреблению ресурсов.

Решение#

Добавьте сведения из предупреждения в zipfile по адресу https://github.com/python/cpython/blob/3.7/Doc/library/zipfile.rst .

Атака ReDoS из-за ненадлежащего использования регулярных выражений glibc#

Симптом#

Интерфейс regcomp/regexec в glibc используется для программирования, а регулярные выражения glibc, такие как grep/sed, используются в командах оболочки. Ненадлежащие регулярные выражения или входные данные используются для ReDoS-атак (CVE-2019-9192/CVE-2018-28796). Типичный шаблон регулярных выражений представляет собой сочетание обратной ссылки “\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)

Возможная причина#

В процессе, использующем регулярное выражение, создается дамп ядра. Регулярное выражение glibc реализуется с использованием гибридного алгоритма недетерминированного/детерминированного конечного автомата (NFA/DFA). Внутренний принцип заключается в использовании жадного алгоритма в рекурсивном запросе для сопоставления как можно большего количества символьных строк. При обработке рекурсивного регулярного выражения жадный алгоритм вызывает ReDoS-атаку.

Решение#

1. Для уменьшения поверхности атаки необходим строгий контроль прав.

2. Убедитесь, что регулярное выражение корректное. Не вводите недопустимые регулярные выражения и не используйте регулярные выражения (ссылки или звездочки) в сочетании со сверхдлинными символьными строками, чтобы не вызвать бесконечную рекурсию.

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

3. Когда пользовательская программа обнаруживает в процессе исключение, она может перезапустить процесс для восстановления сервисов и повышения надежности работы.

Сообщение об ошибке при установке или удалении gdbm-devel в ходе установки или удаления httpd-devel и apr-util-devel#

Симптом#

1. При установке или удалении gdbm-devel-1.18.1-1 сообщается об ошибке.
2. После устранения ошибки 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. В результате внедрить пакет справки при независимой установке gdbm-devel невозможно и отображается следующее предупреждение:

   install-info: No such file or directory for /usr/share/info/gdbm.info.gz
   

2. По умолчанию в системе установлен основной пакет gdbm-1.18.1-1, но не установлен пакет gdbm-devel. Пакеты программного обеспечения, зависящие от gdbm-devel, по-прежнему соответствуют версии основного пакета gdbm и устанавливают gdbm-devel-1.18.1-1. В результате ошибка не исчезает.

Решение#

1. Установите gdbm-1.18.1-2 для обновления gdbm. Ошибка будет исправлена.
2. Обновите gdbm, а затем установите gdbm-devel, чтобы обеспечить зависимость от gdbm более поздней версии. Ошибка будет исправлена.

Сообщение об ошибке rpmdb при выполнении команды yum или dnf после перезагрузки системы#

Симптом#

1. После перезагрузки системы при выполнении связанной с 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 будет поврежден. При выполнении команды dnf или yum появится сообщение об ошибке.

Решение#

Шаг 1. Выполните команду kill -9, чтобы завершить все запущенные команды, связанные с RPM.
Шаг 2. Удалите все файлы /var/lib/rpm/__db.00*.
Шаг 3. Выполните команду rpmdb --rebuilddb, чтобы перестроить базу данных RPM.

Сбой выполнения rpmrebuild -d /home/test filesystem для повторной сборки пакета filesystem#

Симптом#

Не удается выполнить команду rpmrebuild --comment-missing=y --keep-perm -b -d /home/test filesystem-3.16-3.oe1.aarch64 для повторной сборки пакета filesystem. Отображается следующая информация:

/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 создает каталог /proc на этапе %pretrans и изменяет каталог на этапе %ghost, но при работе системы создаются некоторые небольшие процессы. В результате rpmrebuild не может включить эти процессы в пакет, поскольку они не являются файлами или каталогами, и не может выполнить повторную сборку пакета.

Решение#

Не используйте rpmrebuild для повторной сборки пакета filesystem.