39531 2021-01-11 11:41:15 +0300 Ломается база пакетов: db4 error(12) from dbcursor->c_put: Cannot allocate memory 2021-08-30 15:09:39 +0300 1 1 3 Distributions Branch p9 rpm не указана x86_64 Linux CLOSED FIXED P5 normal --- 1 raa qa-team aen glebfm klark lav vseleznv qa-p9 oldest_to_newest 195335 0 raa 2021-01-11 11:41:15 +0300 На p9 на arm64 (RPi3) / amd64 (виртуалка на надёжном сервере) периодически наблюдаю поломку базы пакетов: [root@hw-arm64-alt9 ~]# uname -a Linux hw-arm64-alt9 5.4.64-lts-alt1 #1 SMP Tue Sep 29 13:46:20 UTC 2020 aarch64 GNU/Linux [root@hw-arm64-alt9 ~]# rpm -i lsb-cprocsp-ca-certs-5.0.12041-4.noarch.rpm error: db4 error(12) from dbcursor->c_put: Cannot allocate memory error: error(12) adding header #3057 record error: lsb-cprocsp-ca-certs-5.0.12041-4.noarch: install failed говорят, в db4-4.7.25-20.el6_7 ошибку исправили: https://bugzilla.redhat.com/show_bug.cgi?id=1131457 у меня почти такая версия: [root@hw-arm64-alt9 ~]# rpm -qa|grep db4 libdb4.7-devel-4.7.25-alt9.aarch64 libdb4.7-4.7.25-alt9.aarch64 [root@test-x64-alt9 ~]# rpm -qa|grep db4 libdb4.7-4.7.25-alt9.x86_64 libdb4.7-devel-4.7.25-alt9.x86_64 195340 1 lav 2021-01-11 13:56:28 +0300 > error: db4 error(12) from dbcursor->c_put: Cannot allocate memory Всё же первый вариант — это что у вас действительно не хватает памяти. 195345 2 raa 2021-01-11 15:00:38 +0300 Памяти точно хватает. Вот статистика во время установки: [root@hw-arm64-alt9 ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 312692 98416 388988 0 0 4 16 4 1 4 1 95 0 0 0 0 0 312660 98416 388988 0 0 0 0 8078 60 0 0 100 0 0 ... 1 0 0 312024 98500 388980 0 0 12 0 8300 271 1 1 98 0 0 0 0 0 312140 98500 388988 0 0 0 0 8235 181 1 1 99 0 0 0 0 0 311888 98500 390160 0 0 1168 0 11783 2753 0 1 98 1 0 0 0 0 311824 98500 390160 0 0 0 0 8150 194 0 0 100 0 0 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 311888 98500 390160 0 0 0 0 8176 208 0 0 99 0 0 0 0 0 311888 98500 390160 0 0 0 0 8102 114 0 0 100 0 0 0 0 0 311888 98508 390152 0 0 0 44 8394 449 0 0 100 0 0 0 0 0 311792 98508 390160 0 0 0 0 8053 52 0 0 100 0 0 0 0 0 312392 98516 390152 0 0 0 60 8406 410 0 1 99 0 0 0 0 0 312360 98516 390152 0 0 0 0 8104 104 0 0 100 0 0 0 0 0 312204 98516 390152 0 0 0 0 8146 140 1 0 99 0 0 0 0 0 312108 98516 390152 0 0 0 0 8143 127 0 0 99 0 0 0 0 0 312140 98516 390152 0 0 0 0 8118 118 1 0 99 0 0 0 0 0 312140 98516 390152 0 0 0 0 8052 43 0 0 100 0 0 0 0 0 312140 98524 390152 0 0 0 44 8244 249 0 0 100 0 0 0 0 0 312140 98524 390152 0 0 0 0 8057 45 0 0 100 0 0 0 0 0 312140 98524 390152 0 0 0 0 8033 33 0 0 100 0 0 0 0 0 312140 98524 390152 0 0 0 0 8054 40 0 0 100 0 0 0 0 0 312140 98524 390152 0 0 0 0 8040 36 0 0 100 0 0 0 0 0 312076 98532 390144 0 0 0 16 8212 218 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8084 87 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8057 47 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8035 32 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8054 42 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8033 30 0 0 100 0 0 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 312140 98532 390152 0 0 0 0 8060 50 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8037 31 0 0 100 0 0 0 0 0 312140 98532 390152 0 0 0 0 8053 43 0 0 100 0 0 1 0 0 302312 98532 390152 0 0 16 0 8217 177 9 2 90 0 0 0 0 0 313312 98604 390180 0 0 76 4 8772 667 21 1 77 1 0 0 0 0 313368 98604 390200 0 0 0 0 8047 38 0 0 100 0 0 0 0 0 313368 98604 390200 0 0 0 0 8089 89 0 0 100 0 0 0 0 0 313368 98604 390200 0 0 0 0 8104 111 0 0 100 0 0 0 0 0 313336 98604 390200 0 0 0 0 8092 88 0 0 100 0 0 1 0 0 311604 98604 390200 0 0 0 68 8448 450 2 1 98 0 0 1 0 0 291844 98608 390200 0 0 0 40 9037 1247 24 2 73 0 0 12 0 0 272276 98608 392136 0 0 16 240 11553 4671 24 10 66 1 0 1 0 0 278636 98608 392032 0 0 68 0 9848 1977 17 15 67 0 0 1 0 0 277140 98608 392072 0 0 60 16 8950 834 17 9 74 0 0 1 0 0 268828 98608 405540 0 0 0 700 12950 5272 11 11 77 1 0 1 0 0 265296 98608 405524 0 0 0 32 8805 684 19 7 73 0 0 1 0 0 265736 98612 407796 0 0 0 3988 26230 18501 10 16 65 9 0 1 0 0 268548 98612 407908 0 0 0 52 8872 757 18 9 74 0 0 1 0 0 263076 98612 408360 0 0 0 164 9665 1746 18 7 73 1 0 1 0 0 262668 98612 408992 0 0 0 232 10356 2418 16 9 74 1 0 1 0 0 264600 98612 409008 0 0 0 108 9440 1416 16 10 73 1 0 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 0 264052 98616 409012 0 0 4 404 10508 2498 19 7 74 1 0 1 0 0 263020 98616 409124 0 0 0 52 8824 772 19 7 74 0 0 1 0 0 260240 98616 411528 0 0 0 116 9870 1837 16 10 74 1 0 0 0 0 286980 98616 413644 0 0 0 72 9106 980 15 5 79 1 0 0 0 0 287108 98616 413596 0 0 0 0 8056 44 0 0 100 0 0 0 0 0 287012 98616 413596 0 0 0 620 11525 4011 0 1 99 0 0 0 0 0 287264 98624 413596 0 0 0 252 9115 1105 0 0 99 1 0 0 0 0 287264 98624 413596 0 0 0 0 8032 28 0 0 100 0 0 0 0 0 287264 98624 413596 0 0 0 0 8050 38 0 0 100 0 0 0 0 0 287264 98624 413596 0 0 0 0 8032 28 0 0 100 0 0 ^C Ошибка повторяется до тех пор, пока не сделаешь rpm --rebuilddb, а дальше исчезает надолго. 201860 3 klark 2021-08-19 20:28:00 +0300 На чём это лучше воспроизводить? Виртуалка с хостом amd64? Сервер ThunderX? Или RPi3? Не совсем понятно. Есть ещё варианты: Байкал-М или RPi4. И насколько интенсивно нужно ставить/удалять пакеты, чтобы поймать эту ошибку? 201863 4 vseleznv 2021-08-19 22:15:33 +0300 Проверьте, воспроизводится ли с libdb4.7 из задания 283466. 201866 5 aen 2021-08-19 22:31:53 +0300 (Ответ для Vladimir D. Seleznev на комментарий #4) > Проверьте, воспроизводится ли с libdb4.7 из задания 283466. Андрей, вот тут результаты задания: http://git.altlinux.org/tasks/283466/ 4.7.25-alt9.p9.1 - Do not access DB_CONFIG when env->db_home is not set (fixes: CVE-2017-10140). - Applied upstream patch for multithreaded env_region issues (closes #39531). А чтобы мы могли проверить, ответьте на вопрос Леонида, пожалуйста. 201888 6 raa 2021-08-20 12:51:01 +0300 (In reply to Leonid Krivoshein from comment #3) > На чём это лучше воспроизводить? Виртуалка с хостом amd64? Сервер ThunderX? У меня на amd64-виртуалке воспроизводится с за 10 установок КриптоПро CSP по install.sh: [root@test-x64-alt9 ~]# for i in {1..10}; do ./install.sh || break; done Обращу внимание, что сам rpm при этом ошибок не возвращает: просто наши тесты ловят и текст "error", который прилетает в консоль. Обновлённые пакеты поставлю и послежу. 201898 7 klark 2021-08-20 16:50:04 +0300 (In reply to Андрей Русев from comment #6) > У меня на amd64-виртуалке воспроизводится с за 10 установок КриптоПро CSP А после apt-repo test 283466 воспроизводится? 201932 8 raa 2021-08-21 21:20:30 +0300 После такого обновления проблема воспроизводится: rpm -U ./libdb4.7-4.7.25-alt9.p9.1.x86_64.rpm ./libdb4.7-devel-4.7.25-alt9.p9.1.x86_64.rpm Было: [root@test-x64-alt9 ~]# rpm -qvi libdb4.7-4.7.25-alt9.x86_64 Name : libdb4.7 Version : 4.7.25 Release : alt9 Architecture: x86_64 Install Date: Thu Nov 14 18:09:11 2019 Group : System/Libraries Size : 1346398 License : BSD-style Signature : DSA/SHA1, Sat Mar 25 13:42:11 2017, Key ID 95c584d5ae4ae412 Source RPM : libdb4.7-4.7.25-alt9.src.rpm Build Date : Sat Mar 25 13:40:56 2017 Build Host : vseleznv-sisyphus.hasher.altlinux.org Relocations : (not relocatable) Packager : Vladimir D. Seleznev <vseleznv@altlinux.org> Vendor : ALT Linux Team URL : http://www.oracle.com/technology/products/berkeley-db/db/index.html Summary : Berkeley database library Description : The Berkeley Database (Berkeley DB) is a programmatic toolkit that provides embedded database support for both traditional and client/server applications. Berkeley DB is used by many applications, including Python and Perl, so this should be installed on all systems. Стало: [root@test-x64-alt9 ~]# rpm -qvi libdb4.7-4.7.25-alt9.p9.1.x86_64 Name : libdb4.7 Version : 4.7.25 Release : alt9.p9.1 DistTag : p9+283466.100.1.1 Architecture: x86_64 Install Date: Sat Aug 21 21:13:49 2021 Group : System/Libraries Size : 1354518 License : Sleepycat Signature : RSA/SHA1, Thu Aug 19 21:57:44 2021, Key ID 2b6b82cb7aed4d09 Source RPM : libdb4.7-4.7.25-alt9.p9.1.src.rpm Build Date : Thu Aug 19 21:57:14 2021 Build Host : vseleznv-p9.hasher.altlinux.org Relocations : (not relocatable) Packager : Vladimir D. Seleznev <vseleznv@altlinux.org> Vendor : ALT Linux Team URL : https://www.oracle.com/database/technologies/related/berkeleydb-downloads.html Summary : Berkeley database library Description : The Berkeley Database (Berkeley DB) is a programmatic toolkit that provides embedded database support for both traditional and client/server applications. Berkeley DB is used by many applications, including Python and Perl, so this should be installed on all systems. 201936 9 klark 2021-08-21 23:52:40 +0300 Всё понятно, спасибо! Попробуем воспроизвести на amd64 без перепаковки и с использованием этого инструмента: https://www.altlinux.org/RPM-repair для перепаковки Ваших RPM'ок. А если ставить RPM-пакеты из репозитория, т.е. собранные в нашей сборочнице, проблема тоже воспроизводится? 201956 10 raa 2021-08-23 10:54:42 +0300 Взял ваш небольшой пакет наугад - воспроизводится: [root@test-x64-alt9 ~]# for i in {1..20}; do rpm -e ctags-5.8-alt2.x86_64; rpm -i /home/raa/tmp/_del/alt9_rpm_db_fail/ctags-5.8-alt2.x86_64.rpm || break; done|grep error error: db4 error(12) from dbenv->open: Cannot allocate memory error: db4 error(12) from dbenv->close: Cannot allocate memory error: cannot open Packages index using db4 - Cannot allocate memory (12) error: cannot open Packages database in /var/lib/rpm 201977 11 vseleznv 2021-08-23 18:00:27 +0300 (In reply to Андрей Русев from comment #10) > Взял ваш небольшой пакет наугад - воспроизводится: > [root@test-x64-alt9 ~]# for i in {1..20}; do rpm -e ctags-5.8-alt2.x86_64; > rpm -i /home/raa/tmp/_del/alt9_rpm_db_fail/ctags-5.8-alt2.x86_64.rpm || > break; done|grep error > error: db4 error(12) from dbenv->open: Cannot allocate memory > error: db4 error(12) from dbenv->close: Cannot allocate memory > error: cannot open Packages index using db4 - Cannot allocate memory (12) > error: cannot open Packages database in /var/lib/rpm Запустил на продолжительное время в окружении p9 в вечном цикле удаление и установку указанного ctags. Не воспроизвелось. Надо смотреть на вашей конфигурации. 201979 12 aen 2021-08-23 18:08:37 +0300 Андрей, можно получить описание вашей конфигурации? Результат Владимира для меня был предсказуем, так как несмотря на большую базу установки и регулярные обновления, в том числе весьма большие, у нас такое не вылезало. Конечно, и не должно вылезать ни в каких конфигурациях. Но надо воспроизвести. Спасибо. 201991 13 raa 2021-08-24 10:23:17 +0300 Можно. Только скажите, что описать. Часть я дал в первом сообщении: у нас одинаково воспроизводится на всех двух девятых Альтах: * виртуалка на vmware esxi (amd64) * Raspberry Pi 3 Model B (aarch64) При этом на аналогичных виртуалках на vmware esxi (amd64/i586) на Alt 6/7/8 не воспроизводится. 201997 14 aen 2021-08-24 12:44:22 +0300 (Ответ для Андрей Русев на комментарий #13) > Можно. Только скажите, что описать. Часть я дал в первом сообщении: у нас > одинаково воспроизводится на всех двух девятых Альтах: > * виртуалка на vmware esxi (amd64) > * Raspberry Pi 3 Model B (aarch64) 1. Какой минорный релиз (0,1,2), можно имя файла с образом. 2. Было ли обновление (dist-uprade) из p9 3. Была ли устакновка сторонних пакетов. 4. На всякий случай. Версия vmware 201998 15 raa 2021-08-24 13:05:03 +0300 1. Образы найти не смог. Как получить минор, точно не знаю. AMD64: [root@test-x64-alt9 ~]# cat /etc/*release* ALT Server 9.0 (FalcoRusticolus) ALT Server 9.0 (FalcoRusticolus) LSB_VERSION="core-3.0-noarch:core-4.0-noarch:core-3.0-amd64:core-4.0-amd64" DISTRIB_ID="ALT" LSB_VERSION="4.0" # # Examples: # # DISTRIB_ID - single word, ID of DISTRIBUTOR # DISTRIB_RELEASE="5.0.0" # DISTRIB_CODENAME="Lycoris Radiata" # DISTRIB_DESCRIPTION="ALT Linux Sisyphus (20081222)" # DISTRIB_DESCRIPTION="ALT Linux 1.0.0 Server Light r1 (Lycoris Radiata)" cat: /etc/lsb-release.d: Is a directory NAME="ALT Server" VERSION="9.0" ID=altlinux VERSION_ID=9.0 PRETTY_NAME="ALT Server 9.0 (FalcoRusticolus)" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:server:9.0" HOME_URL="https://basealt.ru/" BUG_REPORT_URL="https://bugs.altlinux.org/" ALT Server 9.0 (FalcoRusticolus) ALT Server 9.0 (FalcoRusticolus) ARM64: [root@hw-arm64-alt9 ~]# cat /etc/*release* ALT p9 starter kit (Hypericum) ALT p9 starter kit (Hypericum) ALT p9 starter kit (Hypericum) LSB_VERSION="core-3.0-noarch:core-4.0-noarch:core-3.0-aarch64:core-4.0-aarch64" DISTRIB_ID="ALT" LSB_VERSION="4.0" # # Examples: # # DISTRIB_ID - single word, ID of DISTRIBUTOR # DISTRIB_RELEASE="5.0.0" # DISTRIB_CODENAME="Lycoris Radiata" # DISTRIB_DESCRIPTION="ALT Linux Sisyphus (20081222)" # DISTRIB_DESCRIPTION="ALT Linux 1.0.0 Server Light r1 (Lycoris Radiata)" cat: /etc/lsb-release.d: Is a directory NAME="starter kit" VERSION="p9 (Hypericum)" ID=altlinux VERSION_ID=p9 PRETTY_NAME="ALT Starterkit (Hypericum)" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:starterkit:p9" HOME_URL="http://en.altlinux.org/starterkits" BUG_REPORT_URL="https://bugs.altlinux.org/" ALT p9 starter kit (Hypericum) ALT p9 starter kit (Hypericum) 2. dist-uprade, вроде бы, не делали. 3. Сторонние пакеты - только наши. В том числе модули ядра, собранные локально (у нас СКЗИ и для ядра есть). 4. VMware ESXi, 6.0.0, 15517548. uptime у машин десятки и сотни дней, так что ошибки могли "накопиться", но смущает, что из сотни машин проблема проявляется только на девятых Альтах. 201999 16 aen 2021-08-24 13:23:11 +0300 Попробуйте обновить систему до текущего p9 : apt-get update apt-get dist-upgrade с текущей или с образов 9.2 https://mirror.yandex.ru/altlinux/p9/images/workstation/ 202002 17 raa 2021-08-24 14:39:22 +0300 (In reply to AEN from comment #16) Обновил. Сразу после обновления макетный тест не выявляет проблему: [root@test-x64-alt9 ~]# for i in {1..20}; do rpm -e ctags-5.8-alt2.x86_64; rpm -i /home/raa/tmp/_del/alt9_rpm_db_fail/ctags-5.8-alt2.x86_64.rpm || break; done|grep error Возможно, дело в том, что большое обновление в чём-то эквивалентно rpm --rebuilddb (после которого ошибка может исчезнуть надолго). По фактическому поведению запрос закрываю. А наши ночные тесты продолжают мониторить ситуацию. Если проблема возникнет снова - переоткрою. 202003 18 raa 2021-08-24 14:54:45 +0300 Без перезагрузки arm64-машина-таки повторила проблему: rpm -i /home/ftp/pub/4_0//linux-arm64_gcc48/64armrelease/latest/64armrelease/cprocsp-rdr-cpfkc-64-5.0.12256-4.noarch.rpm error: db4 error(12) from dbenv->open: Cannot allocate memory error: db4 error(12) from dbenv->close: Cannot allocate memory error: cannot open Packages index using db4 - Cannot allocate memory (12) error: cannot open Packages database in /var/lib/rpm 202128 19 vseleznv 2021-08-30 07:33:06 +0300 Не смог воспроизвести проблему ни на x86_64, ни на aarch64. 202131 20 raa 2021-08-30 11:38:23 +0300 Выполнил перезагрузку после обновления - с тех пор (уже 6 дней) ошибка не появлялась ни на arm64, ни на x64. 202136 21 klark 2021-08-30 14:37:37 +0300 Андрей Андреевич, мы проверяли на версии 5.0.12000, у Вас сборка 5.0.12041-4. Может, дело в этом. Если передадите мне новую сборку через gost@, попробую ещё раз на p9. 202139 22 raa 2021-08-30 15:07:55 +0300 От сборки CSP это не зависит: проблема была на любых пакетах (см. ctags выше). Но сейчас, кажется, уже ничего не надо делать: после обновления Альта и перезагрузки проблема ушла. 202140 23 klark 2021-08-30 15:09:39 +0300 Хорошо, тогда пока закрываем.