[devel] I: rpm macroses for systemd

[devel] I: rpm macroses for systemd

[Alexey Shabalin]

День добрый.
Есть пара новостей для анонса.

rpm макросы, используемые в апстрим (а также в RH, SUSE),
https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
добавлены в сизиф, но разнесены по двум пакетам: rpm-build и
rpm-build-systemd(rpm-macros-systemd)

1) В rpm-build расширен набор макросов с указанием путей для различных
компонентов systemd.
http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=01d2120325bd565dd69fab5473acdf7f13b3a322
По просьбе ldv@ макросы имеют более короткие и читаемые имена
(например вместо %_systemdusergeneratordir используется
%_user_gen_dir), но совместимость с апстримными макросами сохранена и
их тоже можно использовать.

2) rpm-build-systemd виртуальный пакет с зависимостями на
rpm-macros-systemd, systemd-utils, libsystemd-devel (что бы
устанавливались pkgconfig(libsystemd) и pkgconfig(systemd))
Типовое использование:
BuildRequires(pre): rpm-build-systemd
или
BuildRequires(pre): rpm-macros-systemd
BuildRequires: rpm-build-systemd

3) В rpm-build-systemd добавлены макросы для использования в разделах
%post, %preun, %postun
В /usr/lib/rpm/macros.d/systemd в комментариях можно посмотреть
варианты использования.

- %post_systemd и %preun_systemd полностью повторяют логику работы
%post_service и %preun_service. Но в отличие от *_service им за раз
можно указать несколько unit-файлов, systemd сам разберется в
очередности перезагрузки сервисов.
Пример использования:
-----------------
%post
%post_systemd demo.socket demo.service demo1

%preun
%preun_systemd demo.socket demo.service demo1
-----------------

Начиная с systemd-v248 добавлена возможность пометить сервис для
рестарта (systemctl set-property foo.service Markers=+needs-restart),
а потом за раз все помеченные сервисы рестартовать (systemctl
reload-or-restart --marked). Это позволяет реализовать отложенный
рестарт сервиса в конце транзакции при обновлении. Может быть
актуально для множества ПО, порезанного на подпакеты с плагинами, или
другого многокомпонентного ПО, где трудно предсказать очередность
обновления подсистем и желательно рестартовать сервис после обновления
всех пакетов в системе.

Команда "systemctl reload-or-restart --marked"  добавлена в
rpm-filetrigger в systemd-249.3-alt2(уже в сизифе).

Для использования в %post и %preun возможны 2 варианта:
- %post_systemd_restart_later - похож на %post_systemd(и на
%post_service) только не рестартует сервис, а помечает для рестарта.
Тоже возможно указание нескольких unit одновременно.
Пример использования:
-----------------
%post
%post_systemd_restart_later demo.socket demo.service demo1

%preun
%preun_systemd demo.socket demo.service demo1
-----------------

- %systemd_post %systemd_preun  %systemd_postun_with_restart -
апстримные макросы.
Разница в том, что юнит помечается для рестарта при удалении старого
пакета в %postun, т.е. должен быть в предыдущей версии пакета.
Возможно для новых пакетов в репо(и в системе) это не проблема, а для
уже установленных может вызвать проблему, т.к. при обновлении сервис
не будет перезапущен.
В первую очередь эти макросы добавлены для совместимости с апстримом,
и для тех, кто использует copy-paste из спеков других дистрибутивов.
Пример использования:
-----------------
%post
%systemd_post demo.socket demo.service demo1.service
%systemd_user_post demo2.socket demo2.service demo3.service

%preun
%systemd_preun demo.service demo1.service
%systemd_user_preun demo2.socket demo2.service demo3.service

# For restart service at transaction end with rpm-filetrigger, add
%postun
%systemd_postun_with_restart demo.service
----------------


PS: если кто перенесет на wiki, буду признателен.

-- 
Alexey Shabalin

Re: [devel] I: rpm macroses for systemd

[Alexey Shabalin]

пт, 27 авг. 2021 г. в 14:47, Alexey Shabalin <a.shabalin@gmail.com>:
>
> День добрый.
> Есть пара новостей для анонса.
>
> rpm макросы, используемые в апстрим (а также в RH, SUSE),
> https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
> добавлены в сизиф, но разнесены по двум пакетам: rpm-build и
> rpm-build-systemd(rpm-macros-systemd)
>
> 1) В rpm-build расширен набор макросов с указанием путей для различных
> компонентов systemd.
> http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=01d2120325bd565dd69fab5473acdf7f13b3a322
> По просьбе ldv@ макросы имеют более короткие и читаемые имена
> (например вместо %_systemdusergeneratordir используется
> %_user_gen_dir), но совместимость с апстримными макросами сохранена и
> их тоже можно использовать.
>
> 2) rpm-build-systemd виртуальный пакет с зависимостями на
> rpm-macros-systemd, systemd-utils, libsystemd-devel (что бы
> устанавливались pkgconfig(libsystemd) и pkgconfig(systemd))
> Типовое использование:
> BuildRequires(pre): rpm-build-systemd
> или
> BuildRequires(pre): rpm-macros-systemd
> BuildRequires: rpm-build-systemd
>
> 3) В rpm-build-systemd добавлены макросы для использования в разделах
> %post, %preun, %postun
> В /usr/lib/rpm/macros.d/systemd в комментариях можно посмотреть
> варианты использования.
>
> - %post_systemd и %preun_systemd полностью повторяют логику работы
> %post_service и %preun_service. Но в отличие от *_service им за раз
> можно указать несколько unit-файлов, systemd сам разберется в
> очередности перезагрузки сервисов.
> Пример использования:
> -----------------
> %post
> %post_systemd demo.socket demo.service demo1
>
> %preun
> %preun_systemd demo.socket demo.service demo1
> -----------------
>
> Начиная с systemd-v248 добавлена возможность пометить сервис для
> рестарта (systemctl set-property foo.service Markers=+needs-restart),
> а потом за раз все помеченные сервисы рестартовать (systemctl
> reload-or-restart --marked). Это позволяет реализовать отложенный
> рестарт сервиса в конце транзакции при обновлении. Может быть
> актуально для множества ПО, порезанного на подпакеты с плагинами, или
> другого многокомпонентного ПО, где трудно предсказать очередность
> обновления подсистем и желательно рестартовать сервис после обновления
> всех пакетов в системе.
>
> Команда "systemctl reload-or-restart --marked"  добавлена в
> rpm-filetrigger в systemd-249.3-alt2(уже в сизифе).
>
> Для использования в %post и %preun возможны 2 варианта:
> - %post_systemd_restart_later - похож на %post_systemd(и на
> %post_service) только не рестартует сервис, а помечает для рестарта.
> Тоже возможно указание нескольких unit одновременно.
> Пример использования:
> -----------------
> %post
> %post_systemd_restart_later demo.socket demo.service demo1
>
> %preun
> %preun_systemd demo.socket demo.service demo1
> -----------------
>
> - %systemd_post %systemd_preun  %systemd_postun_with_restart -
> апстримные макросы.
> Разница в том, что юнит помечается для рестарта при удалении старого
> пакета в %postun, т.е. должен быть в предыдущей версии пакета.
> Возможно для новых пакетов в репо(и в системе) это не проблема, а для
> уже установленных может вызвать проблему, т.к. при обновлении сервис
> не будет перезапущен.
> В первую очередь эти макросы добавлены для совместимости с апстримом,
> и для тех, кто использует copy-paste из спеков других дистрибутивов.
> Пример использования:
> -----------------
> %post
> %systemd_post demo.socket demo.service demo1.service
> %systemd_user_post demo2.socket demo2.service demo3.service
>
> %preun
> %systemd_preun demo.service demo1.service
> %systemd_user_preun demo2.socket demo2.service demo3.service
>
> # For restart service at transaction end with rpm-filetrigger, add
> %postun
> %systemd_postun_with_restart demo.service
> ----------------
>
>
> PS: если кто перенесет на wiki, буду признателен.
>


Забыл, плюс еще пастримные макросы %tmpfiles_create, %sysusers_create,
%sysusers_create_package, %tmpfiles_create_package, %sysctl_apply,
%binfmt_apply.
Что они делают и примеры тоже можно посмотреть
/usr/lib/rpm/macros.d/systemd, вроде ничего сложного, должно быть
понятно.
Если возникнут вопросы, обращайтесь.

-- 
Alexey Shabalin

Re: [devel] I: rpm macroses for systemd

[Vladimir D. Seleznev]

On Fri, Aug 27, 2021 at 02:51:56PM +0300, Alexey Shabalin wrote:
> пт, 27 авг. 2021 г. в 14:47, Alexey Shabalin <a.shabalin@gmail.com>:
> >
> > День добрый.

Добрый день!

> > Есть пара новостей для анонса.
> >
> > rpm макросы, используемые в апстрим (а также в RH, SUSE),
> > https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
> > добавлены в сизиф, но разнесены по двум пакетам: rpm-build и
> > rpm-build-systemd(rpm-macros-systemd)
> >
> > 1) В rpm-build расширен набор макросов с указанием путей для различных
> > компонентов systemd.
> > http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=01d2120325bd565dd69fab5473acdf7f13b3a322
> > По просьбе ldv@ макросы имеют более короткие и читаемые имена
> > (например вместо %_systemdusergeneratordir используется
> > %_user_gen_dir), но совместимость с апстримными макросами сохранена и
> > их тоже можно использовать.
> >
> > 2) rpm-build-systemd виртуальный пакет с зависимостями на
> > rpm-macros-systemd, systemd-utils, libsystemd-devel (что бы
> > устанавливались pkgconfig(libsystemd) и pkgconfig(systemd))
> > Типовое использование:
> > BuildRequires(pre): rpm-build-systemd
> > или
> > BuildRequires(pre): rpm-macros-systemd
> > BuildRequires: rpm-build-systemd

А когда это нужно?

> > 3) В rpm-build-systemd добавлены макросы для использования в разделах
> > %post, %preun, %postun
> > В /usr/lib/rpm/macros.d/systemd в комментариях можно посмотреть
> > варианты использования.
> >
> > - %post_systemd и %preun_systemd полностью повторяют логику работы
> > %post_service и %preun_service. Но в отличие от *_service им за раз
> > можно указать несколько unit-файлов, systemd сам разберется в
> > очередности перезагрузки сервисов.
> > Пример использования:
> > -----------------
> > %post
> > %post_systemd demo.socket demo.service demo1
> >
> > %preun
> > %preun_systemd demo.socket demo.service demo1
> > -----------------

И что делать тем, у кого в пакетах помимо service-файлов ещё и
init-скрипты?

> > [skip]
> 
> Забыл, плюс еще пастримные макросы %tmpfiles_create, %sysusers_create,
> %sysusers_create_package, %tmpfiles_create_package, %sysctl_apply,
> %binfmt_apply.
> Что они делают и примеры тоже можно посмотреть
> /usr/lib/rpm/macros.d/systemd, вроде ничего сложного, должно быть
> понятно.
> Если возникнут вопросы, обращайтесь.

У меня возникли вопросы к макросам, обозначенным в последнем абзаце,
точнее их необходимости.  Управлять tmpfiles всё-таки надо через
tmpfiles.d, а изменять состояния sysctl и binfmt в результате установки,
обновления или удаления пакетов мне видится неправильным.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] I: rpm macroses for systemd

[Alexey Shabalin]

пт, 27 авг. 2021 г. в 17:42, Vladimir D. Seleznev <vseleznv@altlinux.org>:
>
> On Fri, Aug 27, 2021 at 02:51:56PM +0300, Alexey Shabalin wrote:
> > пт, 27 авг. 2021 г. в 14:47, Alexey Shabalin <a.shabalin@gmail.com>:
> > >
> > > День добрый.
>
> Добрый день!
>
> > > Есть пара новостей для анонса.
> > >
> > > rpm макросы, используемые в апстрим (а также в RH, SUSE),
> > > https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
> > > добавлены в сизиф, но разнесены по двум пакетам: rpm-build и
> > > rpm-build-systemd(rpm-macros-systemd)
> > >
> > > 1) В rpm-build расширен набор макросов с указанием путей для различных
> > > компонентов systemd.
> > > http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=01d2120325bd565dd69fab5473acdf7f13b3a322
> > > По просьбе ldv@ макросы имеют более короткие и читаемые имена
> > > (например вместо %_systemdusergeneratordir используется
> > > %_user_gen_dir), но совместимость с апстримными макросами сохранена и
> > > их тоже можно использовать.
> > >
> > > 2) rpm-build-systemd виртуальный пакет с зависимостями на
> > > rpm-macros-systemd, systemd-utils, libsystemd-devel (что бы
> > > устанавливались pkgconfig(libsystemd) и pkgconfig(systemd))
> > > Типовое использование:
> > > BuildRequires(pre): rpm-build-systemd
> > > или
> > > BuildRequires(pre): rpm-macros-systemd
> > > BuildRequires: rpm-build-systemd
>
> А когда это нужно?

Это нужно, когда это нужно :)
Очевидно, что когда хочется воспользоваться макросами, или когда нужна
сборочная зависимость на pkgconfig(systemd).
Или я не понял в чем вопрос.

>
> > > 3) В rpm-build-systemd добавлены макросы для использования в разделах
> > > %post, %preun, %postun
> > > В /usr/lib/rpm/macros.d/systemd в комментариях можно посмотреть
> > > варианты использования.
> > >
> > > - %post_systemd и %preun_systemd полностью повторяют логику работы
> > > %post_service и %preun_service. Но в отличие от *_service им за раз
> > > можно указать несколько unit-файлов, systemd сам разберется в
> > > очередности перезагрузки сервисов.
> > > Пример использования:
> > > -----------------
> > > %post
> > > %post_systemd demo.socket demo.service demo1
> > >
> > > %preun
> > > %preun_systemd demo.socket demo.service demo1
> > > -----------------
>
> И что делать тем, у кого в пакетах помимо service-файлов ещё и
> init-скрипты?

Ничего не делать, продолжать жить дальше и использовать %post_service
и %preun_service.
Новые макросы systemd-only, поэтому они в пакете rpm-macros-systemd.
У нас сейчас есть довольно много пакетов, которые не предусматривают
работу под sysvinit.
Например, ceph, в нем в принципе все заточено для работы под systemd,
используются юниты вида ceph-osd@3.service, ceph-mon@server1.service.
И рестартовать сервисы хотелось бы в конце транзакции.
Или я опять не понял в чем вопрос.

Реализовывать отложенный рестарт сервисов под sysvinit нужно каким-то
другим способом.
Сейчас как это сделать, каждый пакет придумывает самостоятельно.

>
> > > [skip]
> >
> > Забыл, плюс еще пастримные макросы %tmpfiles_create, %sysusers_create,
> > %sysusers_create_package, %tmpfiles_create_package, %sysctl_apply,
> > %binfmt_apply.
> > Что они делают и примеры тоже можно посмотреть
> > /usr/lib/rpm/macros.d/systemd, вроде ничего сложного, должно быть
> > понятно.
> > Если возникнут вопросы, обращайтесь.
>
> У меня возникли вопросы к макросам, обозначенным в последнем абзаце,
> точнее их необходимости.  Управлять tmpfiles всё-таки надо через
> tmpfiles.d, а изменять состояния sysctl и binfmt в результате установки,
> обновления или удаления пакетов мне видится неправильным.

Не используйте. Я вижу что вы макросы не читали, но осуждаете.

А мне вот нужна необходимость упаковать что-то sysctl.d и применить до
рестарта сервиса, а не дожидаться когда отработает filetrigger или
сервер перезагрузится.


-- 
Alexey Shabalin

Re: [devel] I: rpm macroses for systemd

[Vladimir D. Seleznev]

On Fri, Aug 27, 2021 at 07:00:33PM +0300, Alexey Shabalin wrote:
> пт, 27 авг. 2021 г. в 17:42, Vladimir D. Seleznev <vseleznv@altlinux.org>:
> >
> > On Fri, Aug 27, 2021 at 02:51:56PM +0300, Alexey Shabalin wrote:
> > > пт, 27 авг. 2021 г. в 14:47, Alexey Shabalin <a.shabalin@gmail.com>:
> > > >
> > > > День добрый.
> >
> > Добрый день!
> >
> > > > Есть пара новостей для анонса.
> > > >
> > > > rpm макросы, используемые в апстрим (а также в RH, SUSE),
> > > > https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
> > > > добавлены в сизиф, но разнесены по двум пакетам: rpm-build и
> > > > rpm-build-systemd(rpm-macros-systemd)
> > > >
> > > > 1) В rpm-build расширен набор макросов с указанием путей для различных
> > > > компонентов systemd.
> > > > http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=01d2120325bd565dd69fab5473acdf7f13b3a322
> > > > По просьбе ldv@ макросы имеют более короткие и читаемые имена
> > > > (например вместо %_systemdusergeneratordir используется
> > > > %_user_gen_dir), но совместимость с апстримными макросами сохранена и
> > > > их тоже можно использовать.
> > > >
> > > > 2) rpm-build-systemd виртуальный пакет с зависимостями на
> > > > rpm-macros-systemd, systemd-utils, libsystemd-devel (что бы
> > > > устанавливались pkgconfig(libsystemd) и pkgconfig(systemd))
> > > > Типовое использование:
> > > > BuildRequires(pre): rpm-build-systemd
> > > > или
> > > > BuildRequires(pre): rpm-macros-systemd
> > > > BuildRequires: rpm-build-systemd
> >
> > А когда это нужно?
> 
> Это нужно, когда это нужно :)
> Очевидно, что когда хочется воспользоваться макросами, или когда нужна
> сборочная зависимость на pkgconfig(systemd).
> Или я не понял в чем вопрос.
> 
> >
> > > > 3) В rpm-build-systemd добавлены макросы для использования в разделах
> > > > %post, %preun, %postun
> > > > В /usr/lib/rpm/macros.d/systemd в комментариях можно посмотреть
> > > > варианты использования.
> > > >
> > > > - %post_systemd и %preun_systemd полностью повторяют логику работы
> > > > %post_service и %preun_service. Но в отличие от *_service им за раз
> > > > можно указать несколько unit-файлов, systemd сам разберется в
> > > > очередности перезагрузки сервисов.
> > > > Пример использования:
> > > > -----------------
> > > > %post
> > > > %post_systemd demo.socket demo.service demo1
> > > >
> > > > %preun
> > > > %preun_systemd demo.socket demo.service demo1
> > > > -----------------
> >
> > И что делать тем, у кого в пакетах помимо service-файлов ещё и
> > init-скрипты?
> 
> Ничего не делать, продолжать жить дальше и использовать %post_service
> и %preun_service.
> Новые макросы systemd-only, поэтому они в пакете rpm-macros-systemd.
> У нас сейчас есть довольно много пакетов, которые не предусматривают
> работу под sysvinit.
> Например, ceph, в нем в принципе все заточено для работы под systemd,
> используются юниты вида ceph-osd@3.service, ceph-mon@server1.service.
> И рестартовать сервисы хотелось бы в конце транзакции.
> Или я опять не понял в чем вопрос.
> 
> Реализовывать отложенный рестарт сервисов под sysvinit нужно каким-то
> другим способом.
> Сейчас как это сделать, каждый пакет придумывает самостоятельно.

Спасибо, стало понятнее.

> >
> > > > [skip]
> > >
> > > Забыл, плюс еще пастримные макросы %tmpfiles_create, %sysusers_create,
> > > %sysusers_create_package, %tmpfiles_create_package, %sysctl_apply,
> > > %binfmt_apply.
> > > Что они делают и примеры тоже можно посмотреть
> > > /usr/lib/rpm/macros.d/systemd, вроде ничего сложного, должно быть
> > > понятно.
> > > Если возникнут вопросы, обращайтесь.
> >
> > У меня возникли вопросы к макросам, обозначенным в последнем абзаце,
> > точнее их необходимости.  Управлять tmpfiles всё-таки надо через
> > tmpfiles.d, а изменять состояния sysctl и binfmt в результате установки,
> > обновления или удаления пакетов мне видится неправильным.
> 
> Не используйте. Я вижу что вы макросы не читали, но осуждаете.

Как раз-таки читал и осуждаю.

> А мне вот нужна необходимость упаковать что-то sysctl.d и применить до
> рестарта сервиса, а не дожидаться когда отработает filetrigger или
> сервер перезагрузится.

Вот как-раз таки такое поведение мне кажется неправильным. Установка,
обновление или удаление пакета с сервисами не должно приводить к
изменению конфигурации sysctl, это зона ответственности системного
администратора. Единственный случай, при котором мне кажется это
допустимо, это сервисы, перезагружающие модуля ядра с последующим
применением (восстановлением, в данном случае) конфигурации
sysctl-параметров, которые данный модуль предоставляет (но это
вырожденный пример). Ну, или ещё вариант, что я ничего не понимаю в
современных Линуксах.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] I: rpm macroses for systemd

[Evgeny Sinelnikov]

пн, 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 уже приехало? Разве от него
далее что-то зависит? Вопрос в том только когда оно успеет отработать
- сразу попозже, сразу по-раньше или после перезагрузки.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] I: rpm macroses for systemd

[Vladimir D. Seleznev]

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