Перезагрузка псевдодемонов в systemd и её последствия
| Natrio |
|
|
Темы:
48
Сообщения:
4770
Участник с: 08 января 2011
|
Допустим, у нас есть такой псевдодемон: [Unit] Description=Iptables Firewall Wants=network.target Before=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/etc/net/filter start ExecStop=/etc/net/filter stop [Install] WantedBy=multi-user.target Также допустим, что мы хотим, чтобы некоторые демоны запускались только при поднятом фаерволле, и для этого привязываем их к нему через Requires= А потом мы вдруг исправили конфиг файрволла, и хотим обновить правила. Если сделать это через restart, то все “привязанные” к нему демоны тоже перезагрузятся, чего нам совсем не надо. Если же попробовать сделать это через reload, то выясняется, что псевдодемону (Type=oneshot), который фактически не имеет процесса в памяти, невозможно придать параметр ExecReload= , это трактуется как ошибка. Сделать это через start тоже не получится, так как до вызова stop псевдодемон считается запущенным. Спрашивается, что в этом случае делать? Я пока просто убрал Requires, чтобы можно было делать restart но мне это активно не нравится. Конечно, можно обновлять фаерволл и мимо systemd, но пока я всё ещё надеюсь, что удастся обойтись без этого. P.S. Поставил в зависимый юнит Wants= вместо Requires= При старте второй действительно тянет за собой первый, но при отключении первого второй остаётся. Вариант так себе… |
| sleepycat |
|
Темы:
98
Сообщения:
3291
Участник с: 19 июля 2011
|
ятак и не понял чего вы хотите добиться, вы уж определитесь с юнитом, какнито. Вообще то что Вы описываете как бы реагирует так как и должно. Т.е. если мы так строго привязываем один юнит к другому, то понятно дело что он будет как слепой за повадырем. А вообще интуитивно возник вопрос, а на отбой (hup) фильтр не реагирует, я както до системд думал об этом, но этож фильтр а не программа… т.е. в инитскриптах такого шика не было вообще, т.е. подобный вопрос даже не возникал. Здесь же вдруг надо статично привязать фаер к др. демону, однако раз уж есть функционал, надо бы его реализовать. Первое что думается, это методы костылей, т.е. HUP. Второе интуитивное это попробовать найти тип в котором сможем добавить релоад. Вот мой штатный юнит, сегодня вечером попытаюсь чтонито придумать с ним, чтобы без stop обойтись. Написал сугубо для стимуляции мыслей, может кого осенит после прочтения. └─>> cat /usr/lib/systemd/system/iptables.service [Unit] Description=Packet Filtering Framework [Service] Type=oneshot ExecStart=/usr/sbin/iptables-restore /etc/iptables/iptables.rules ExecStop=/usr/lib/systemd/scripts/iptables-flush RemainAfterExit=yes [Install] WantedBy=multi-user.target Если сделать это через restart, то все “привязанные” к нему демоны тоже перезагрузятся, чего нам совсем не надк сожалению так обычно и делают, чтобы не допустить утечки или чегото подобного. Ну по крайнер мере я везде читал такие тенденции, но учитывая тенденции привязки, думаю что решение вопроса будет тоже мне интересно,поэтому я отведу часть времени позже на изучении и отпишусь. Однако для этого мне нужно авансов осилить и как следует понять отношения меж Requires и wants. Может я что найду в мане параллельно . Вопрос страный , вроде бы обычно для такого хватала After, а если привязал то будь добр…. однако как бы так жестко привязать и найти способ “без отдачи”. Думаю все же это не проблема системы как таковой, а проблема юнита…. все сегодня сажусь за мат.часть по юнитам в крайнем случае по служебным, пора бы прояснить все точки над `и`. )))
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
|
| Natrio |
|
|
Темы:
48
Сообщения:
4770
Участник с: 08 января 2011
|
iptables.service тут ничем не лучше. А не использую я его потому, что мне надо перезагрузить только filter, а nat и mangle оставить без изменений. Дело тут даже не в проблеме с “привязкой”, которая в случае псевдодемона без процесса чисто формальная, и формализуется не совсем так, как хотелось бы, а в этом дурацком ограничении на действия с псевдодемоном – start/stop пожалуйста, а reload – не моги. Можно найти и другие аналогичные ситуации, когда такому “демону” безо всякой “привязки” понадобится больше двух действий, а повесить их не на что, даже reload отобрали… |
| sleepycat |
|
|
Темы:
98
Сообщения:
3291
Участник с: 19 июля 2011
|
вообщем удалось заставить прописаться правилам на стандартном конфиге удалив remain after и execstop. 2. я так понимаю (почти перевел все) что в типе форк все работает, что мешает сделать тип форк. как я понял ничего фатального не будет. упд. Торопился, поэтому сейчас уточню, правила стали записываться при повтороном старте, что в моем случае не страшно (конфиг правил на всякий пожарный перед пуском сам сбрасывает правила, поэтому мне для данной задачи стоп не нужен как таковой), но как то все стало выглядить не красиво. Сейчас я переввел текст ман страницы сервисов, могу сказать уверено, что с полем тип в юните можно играть свободно, так как для системд это не указание к действиям а скорее чтото вроде совета, т.е. истина в том, что чем точнее мы опишем процесс тем больше встроенных ффункций сиистемд отработают как надо. Т.е. если мы поставим форк, то система просто будет ждать иксита главного процессса, и только плсе этого оно будет думать, что все красиво и продолжить инициализацию. Natrio можете попробовать с типом форк? будет ли оно читсо гипотетически работать так как надо вам? у меня просто не хватило времени чтобы проверить, адо завтрашнего, т.е . сегоднейшего обеда я походу не проснусь)))
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
|