From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=Pwv9sMHF6KmdSDEUeFXdgdT+Ojtjpon/hwgnAnYYdHc=; b=cvp+wowjvEMVXudgE7XCGUmoxjuROvmWzYrj1WJD/lQ54gikK6RJ5Snh4XwRctGeMi h+Pqv8St241uGBT/xnMla5NvWNK9Gvuj4MpZYLhzs52sHU6/Ke67+KApLxWz/1rmnT8A khcSlmqL0jrFrflb6GmfpqMoZ3bf+eqhPz15fvE3xEbBGruG02JuHr8Lu1r4Xh4OD+eE +7YLR84NIg4tlRkFnyczUJWXar8fZU2t8AwoVmvSHPVy4qKoujjBJYwW1vbs+sebHkEa LX9GsXKQ3XXB0hCH0cmPwqNA2QKRkO90lAZqCjp4k9vTF2FjOluPJrWg7Cm5dboU6c19 QbHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Pwv9sMHF6KmdSDEUeFXdgdT+Ojtjpon/hwgnAnYYdHc=; b=FtyNKPMDQZAb3Z5uwi4UKsxYx2s+Icrn0Nlu7VnuI+OpAbrWtRtbPzm7LoDaXVbckH lAoWH3dFDq1CskLuY8u3vc5rwb4fZkc0wZGJePcduP3hFoBlddb1UMU+1Q1pS7NK9qYR /awaLdCjW75JZ1FQPPclE2jjovJx0cnEAOM4jZOG8FoTCQ5YnaHKLLGyZiNaOIKg9fyE moNTL002M0MJlC5d0Ty0GScBuWxdenNfoCsmEhcWDYfn1YBxkIJm4aB6OVfdEHfwqDMX U7Jw2bx4p18nI+k+53jFb0eup2Uw28SVgb3jfIwAJax+rxbsq2uqf1vSbwhUW94Acb/j 8pwA== X-Gm-Message-State: ACrzQf3JoquXHdVzZzWs0ps9qtKUy5l0E0RpqlleUOO7mlj+ZhMWgYyW H4j4h9lqkVKouHgV+EjdGOtdaHl5Z4Y= X-Google-Smtp-Source: AMsMyM4pO+0oIQ00awX7qfvZJ4htbVc+m2yxhHnRHJhecJvl14kLA0JU2WnmMjGQc54ivHmJS+k7LQ== X-Received: by 2002:a05:6512:3e12:b0:48a:a64f:7228 with SMTP id i18-20020a0565123e1200b0048aa64f7228mr18431257lfv.159.1666816935858; Wed, 26 Oct 2022 13:42:15 -0700 (PDT) Sender: "Ivan A. Melnikov" Date: Thu, 27 Oct 2022 00:42:13 +0400 From: "Ivan A. Melnikov" To: ALT Linux Team development discussions Message-ID: <20221026204213.rla6unpdjtyzs6yj@titan.localdomain> References: <20221023172505.GA8234@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [devel] racket cpu hog (was: CPU time limit exceeded) X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2022 20:42:19 -0000 Archived-At: List-Archive: List-Post: On Wed, Oct 26, 2022 at 10:47:25PM +0300, Anton Zhukharev wrote: > On Mon, Oct 24, 2022 at 10:54:17AM +0300, Anton Zhukharev wrote: > > On Sun, Oct 23, 2022 at 09:52:39PM +0300, Anton Zhukharev wrote: > > > On Sun, Oct 23, 2022 at 08:25:05PM +0300, Dmitry V. Levin wrote: > > > > On Sun, Oct 23, 2022 at 12:39:16PM +0300, Anton Zhukharev wrote: > > > > > Добрый день! > > > > > > > > > > Недавно столкнулся с проблемой следующего вида: > > > > > > > > > > [ppc64le] /usr/sbin/chroot.fakechroot: line 147: 2435617 CPU time limit exceeded env -u FAKECHROOT_BASE_ORIG FAKECHROOT_CMD_ORIG= LD_LIBRARY_PATH="$fakechroot_chroot_paths" FAKECHROOT_BASE="$fakechroot_chroot_base" "$fakechroot_chroot_chroot" "${@:1:$(($fakechroot_chroot_n - 1))}" "$fakechroot_chroot_final_newroot" "${@:$(($fakechroot_chroot_n + 1))}" > > > > > 2022-Oct-22 21:18:00 :: [ppc64le] racket-main-distribution.git 8.6-alt1: remote: build failed > > > > > 2022-Oct-22 21:18:00 :: [ppc64le] #100 racket-main-distribution.git 8.6-alt1: build FAILED > > > > > > > > > > в задании 308872. > > > > > > > > > > Насколько я понимаю, эта ошибка связана с разделением времени работы > > > > > процессора между пользовательскими процессами (воспроизвелась только на > > > > > архитектурах i586, armh и ppc64le - на x86_64 и aarch64 полёт нормальный). > > > > > > > > > > Есть способ обхода такого ограничения? > > > > > > > > Сделать так, чтобы racket перестал быть таким неуёмно прожорливым, > > > > что особенно проявляется на более медленных архитектурах. > > > > > > > Это, конечно, не лучшее решение, но сделав установку Racket-пакетов в > > > 1 поток (-j 1), пакет стал собираться (см. задание 308872). > > > > > > Похоже, что планировщик в установщике пакетов Racket'а работает не очень > > > оптимальным образом. > > > > > > Что ж, решение найдено. Процесс сборки стал дольше (кстати, не сильно), > > > однако мне важен результат, а не скорость. > > > > > > Осталось подлатать и в репозитории будет Racket ;). > > > > > К сожалению, я поспешил с выводами. Этот способ помог только на i586. > > > > Похоже, что придётся дробить (хотелось этого избежать для пакетов > > входящих в main-distribution, однако придётся как-то решить проблему > > взаимозависимостей). > > Дальше много текста, предлагается читать только тем, кому интересна идея > о возвращении в репозиторий Racket (именно современного CS-варианта). > > -- > > Похоже, что раздробить всё таки легко не получится: сейчас попробую "вкраце" > объяснить почему это довольно сложно в случае с Racket. > > Основная проблема заключается в том, что после установки каждого пакета > Racket вносит данные в файл links.rktd (/usr/share/racket/links.rktd), > который содержит ссылки на пакеты (по одному на строку) и ещё > дополнительные данные. Это только половина беды, поскольку решается > (вроде бы) выполнением команды: > > # raco link -i --repair > > Дальше - ещё веселее. Также _необходим_ файл pkgs.rktd > (/usr/lib/racket/pkgs/pkgs.rktd), который необходим практически > для того же для чего нужен и links.rktd (он содержит ссылки на пакеты). > Он также обновляется после каждой установки/обновлении пакета. Если этот > файл повредится/будет удалён/недоступен, то пакетный менеджер raco не > увидит, что в системе установлены Racket-пакеты (в /usr/lib/racket/pkgs) > > В теории, это можно решить созданием независимого пакета, который будет > содержать список со всеми пакетами из main-distribution (однако как его > обновлять в дальнейшем - не совсем ясно: если кому-то понадобится > установить Racket-пакет не входящий в RPM-пакет, то он должен > быть (1) установлен от пользователя root, (2) он изменит файл, который > принадлежит теоретическому независимому пакету (это, на мой взгляд не > совсем правильно) и (3) будет конфликтовать с другими возможными > пакетами с Racket-пакетами). > > Аналогично файлу pkgs.rktd также существуют два файла в > /usr/lib[64]/racket: это launchers.rktd и mans.rktd, которые также > изменяются после установки _некоторых_ пакетов из main-distribution. > Они содержат запускаторы для программ, которые являются Racket-пакетами, > и man-pages соответственно. > > Обновлять файлы pkgs.rktd, launchers.rktd и mans.rktd, возможно, > получится в будущем, когда я (или не я) разберусь с кодовой базой Racket > и создам свой велосипед для их актуализации. Но даже если такой > велосипед будет создан, то не понятно когда его запускать: после > установки каждого RPM-пакета с Racket-пакетами выглядит неоптимально, > поскольку в теории может быть вызвано несколько раз, допустим при > обновлении пакетов или их установки, что сильно увеличит длительность > транзакции установки пакетов. Тут мне нужна помощь: существует ли > возможность выполнения определенного скриптлета 1 раз в конце > транзакции? Ну, допустим есть ли что-то вроде "%post --once"? Письмо читал по диагонали, но кажется Вам сюда: https://www.altlinux.org/RPMFileTrigger > // Ну или диагонально-другая идея: создать systemd-сервис, который > // будет после обновления пакетов проводить операции актуализации > // этих файлов. Здесь нужно ещё думать. > > Сейчас у меня на уме несколько идей, которые нуждаются в, как минимум, > первичных обсуждениях дабы возможные пользователи Racket не испытывали > дискомфорт при использовании его из нашего репозитория: > > 1. Оставить только RPM-пакет racket-core, а пользователей "обязать" > ставить Racket-пакеты себе в домашнюю директорию. (не нравится, к > тому же не работает, поскольку сейчас в репозитории Racket 8.6, а > пакетный менеджер raco пытается ставить пакеты для 8.7, который > ещё в стадии тестирования...) > > 2. Выкинуть архитектуры ppc64le и armh и собирать Racket-пакеты из > main-distribution в один RPM-пакет. (ещё больше не нравится из-за > отказа от некоторых платформ в нашем репозитории) > > 3. Попробовать ставить Racket-пакеты из main-distribution в систему, > используя EEPM (использовать racket-core из репозитория и просто > устанавливать Racket-пакеты в рамках локальной сборки на каждой > пользовательской машине). (нравится, поскольку пакеты будут > установлены в system-scope, не нужно отказываться от некоторых > платформ, а процесс сборки надёжен, поскольку у него небольшие > требования - разве что CPU time) > > 4. "Завелосипедить" свой установщик Racket-пакетов для ALT'а (я в > восторге от этого варианта, но на его реализацию потребуется > неопределенное количество времени). > > Если кому-то интересно о "возможных пользователях Racket", то они могут > появиться после приобретения книги "Как проектировать программы": > > Фелляйзен М., Финдлер Р.Б., Флэтт М.[1], Кришнамурти Ш. > Как проектировать программы / пер. с англ. А.Н. Киселева; под ред. > П.Б. Иванова, А.Д. Чичинина, Ю.А. Сыровецкого, С.В. Бронникова. -М: > ДМК Пресс, 2022. - 724 с.: ил. > > Сайт книги: http://htdp.org/2022-8-7/Book/index.html > > Конечно, таких пользователей может оказаться немного, однако это > неплохой случай занять эту небольшую нишу в области образования. > > -- > [1] - Флэтт М. (он же mflatt) - главный разработчик Racket (по > совместительству его создатель). > > -- > С уважением, > Жухарев Антон > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEncj8Wbn95ehqoNT0ETK72RYVmrMFAmNZjswACgkQETK72RYV > mrOzGRAA1xJR2svrChz4bxiHYZQNaPyyMpgTZDjkE3vwteIy1N8NS6GzUL8sWQtI > nCMT8JkWN/6RnxnzWsCcUSTVHZK7b0ew4KMCgb6v66okECoJkQQiFMAWG2yedG5d > 34B2XTEm21mZChIwsaWDhoaBeSR3ld1nmXlrX9GdxN94BP/q1PvedyHANSUn0yBD > dFV6WBWyeBWZIGXIYL9dXm7djz8SuZsR6zNE0M9pK7B0LiIPOVV5yRj6e+60uM4c > I/nwxXZ0ZQIgArxlyL1prOT+oI6Ez2lZslJrTDBgo3y6SnGEyvH74Tk8SkGosJGX > eQKtz3HkAE2PRZg303UR8YlceM1WmFyLgSHRQLjCHOGd2pPZmCSYSfwO8T16zUZf > +ZBNYwJ7BAoav+wl8kJ6rdL4NZwqMc5ddSWwzG/CdceDA1M4kHUekYS2AVICcFxi > GSt0J2yEgQblK2YgxnYN5XfGJ0MaE3mGjiU7CTcO+cbm3fnamE/RBGcM86s0N9wJ > xgJxfvFbEqbL1cgcb5qYYe1W+h9pu1CSpliKdH73V/l1Q7kwjVmgeot6q4DLgUCb > ngtd3AFwJ0AyO5eRlUJMsQnShqWURDqx1ZJrnjoSGWPL5Scis6QieZatwidvg2AR > u4vz+frH9ibssg2W5DnZWWybpuRoGGh1/uqktA/bV6KaFEmLmUM= > =x12J > -----END PGP SIGNATURE----- > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel