From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vseleznv@altlinux.org>
Date: Thu, 2 Sep 2021 19:45:37 +0000
From: "Vladimir D. Seleznev" <vseleznv@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Message-ID: <YTEp4W/vjP/HxTfr@portlab>
References: <CAEdvWkROU3cSn7tnUczNR6h_xi1_E4thoDjWa1xfE+zCPmaV5Q@mail.gmail.com>
 <CAEdvWkROx_Np+1qjec2AprA5-LZdGWNg3TxvV9qwZxzsycXHvQ@mail.gmail.com>
 <YSj5utKuJs/vQwjY@portlab>
 <CAEdvWkTxVCA9-qSBmpyEj_KFHg6abiF50GcnfnVfSib0k6FPRQ@mail.gmail.com>
 <YS0IbEMo3mUgW8T0@portlab>
 <CAK42-GryocPBxGszXA2JA7w32MN5chu9eSycKgCiT876cXtT3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAK42-GryocPBxGszXA2JA7w32MN5chu9eSycKgCiT876cXtT3Q@mail.gmail.com>
Subject: Re: [devel] I: rpm macroses for systemd
X-BeenThere: devel@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ALT Linux Team development discussions <devel@lists.altlinux.org>
List-Id: ALT Linux Team development discussions <devel.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/devel>,
 <mailto:devel-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/devel>
List-Post: <mailto:devel@lists.altlinux.org>
List-Help: <mailto:devel-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/devel>,
 <mailto:devel-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2021 19:45:37 -0000
Archived-At: <http://lore.altlinux.org/devel/YTEp4W%2FvjP%2FHxTfr@portlab/>
List-Archive: <http://lore.altlinux.org/devel/>
List-Post: <mailto:devel@altlinux.org>

On Thu, Sep 02, 2021 at 12:34:46AM +0400, Evgeny Sinelnikov wrote:
> пн, 30 авг. 2021 г. в 20:33, Vladimir D. Seleznev
> <vseleznv@altlinux.org>:
> >
> > On Fri, Aug 27, 2021 at 07:00:33PM +0300, Alexey Shabalin wrote:
> > > пт, 27 авг. 2021 г. в 17:42, Vladimir D. Seleznev
> > > <vseleznv@altlinux.org>:
> [...]
> > > А мне вот нужна необходимость упаковать что-то sysctl.d и
> > > применить до рестарта сервиса, а не дожидаться когда отработает
> > > filetrigger или сервер перезагрузится.
> >
> > Вот как-раз таки такое поведение мне кажется неправильным.
> > Установка, обновление или удаление пакета с сервисами не должно
> > приводить к изменению конфигурации sysctl, это зона ответственности
> > системного администратора. Единственный случай, при котором мне
> > кажется это допустимо, это сервисы, перезагружающие модуля ядра с
> > последующим применением (восстановлением, в данном случае)
> > конфигурации sysctl-параметров, которые данный модуль предоставляет
> > (но это вырожденный пример). Ну, или ещё вариант, что я ничего не
> > понимаю в современных Линуксах.
> 
> А причём тут сисадмин, если оно в sysctl.d уже приехало? Разве от него
> далее что-то зависит? Вопрос в том только когда оно успеет отработать
> - сразу попозже, сразу по-раньше или после перезагрузки.

Потому что сисадмину следует иметь контроль над системой.

Я сразу же придумал design flaw, когда настройка в /lib/sysctl.d
перебивается настройками, записанными в /etc/sysctl.*, и перезапуск
сервиса заставляет перечитать параметры из файлов, лежащий в
/lib/sysctl.d, ассоциированных с данным сервисом, но оказалось всё не
так плохо: для оверрайдинга параметров ядра, приезжающими с неким
сервисом, страница мануала sysctl.d(5) рекомендует создавать в
/etc/sysctl.d файл с именем, совпадающим с именем файла, находящимся в
/lib/sysctl.d, а для полного выключения — создавать симлинк на
/dev/null. Другое дело, что нужно постоянно мониторить не приехали
интересующие параметры с установкой/обновлением пакетов.

-- 
   WBR,
   Vladimir D. Seleznev