[devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Alexey Gladkov]

On Mon, Dec 07, 2020 at 04:04:01PM +0300, Mikhail Novosyolov wrote:
> 07.12.2020 15:43, Alexey Gladkov пишет:
> > On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
> >> Может, проще init-скрипты вынести в отдельный пакет, которым будет
> >> рулить группа любителей sysvinit? Такой вариант в Альте никогда не
> >> обсуждался?
> > Не обсуждался. Потому что такой подход обречён на провал. init-скрипт
> > будет в роли догоняющего и в какой-то момент случится так, что сервис
> > поменяется, а init-скрипт не будет это учитывать.
> Смотря какое качество сопровождения init-скриптов в среднем по больнице
> сейчас и что будет в будущем, когда то, что в них запускается, будет
> меняться, а тестировать старые скрипты в новых версиях пакетов
> большинство мейнтейнеров не будет.

Это известная проблема (aka "я в домике"). Она существует и для обратного
случая. Например, у меня нет systemd и сервисы для него в моих пакетах
мной не тестируются.

> > Я видел идеи по конвертации systemd-сервисов в init-скрипты, но
> > нормальной реализации не видел, а писать что-то такое для альта нет
> > мотивации.
> Полноценно конвертировать нельзя. Например, в systemd-сервисе
> выставляются capabilities, создается особый mount-namespace, включается
> учет статистики потребления сетевого трафика и i/o. Запускать setcap
> внутри чего-то внутри чего-то внутри чего-то и надеяться, что
> выстроенная цепочка утилит отработает правильно? Или забивать на такое и
> запускать просто от root?

Также как миграция sysv-скриптов в systemd-сервисы не всё учитывает, так и
обратная операция не обязательно всё сможет подхватить.

Для sysvinit мы реализовывали гибкое выставление rlimit. Ничего не мешает
добавить поддержку namespace (для них у меня где-то валялся набросок) и
capabilities.

Утилитам я доверяю больше т.к. их удобнее отлаживать.

-- 
Rgrds, legion