LINUX.ORG.RU

Новый релиз systemd 195

 


0

1

Lennart Poettering продолжает развивать свое творение, внося в него новые возможности. В свежевыпущенный релиз внесены следующие изменения:

  • journalctl получил новые параметры --since= и --until= для фильтрации по времени. Также теперь поддерживается фильтрация по юнитам через --unit=/-u.
  • journald теперь поддерживает ротацию и очистку журнала по времени в дополнение к уже имевшейся ротации по занимаемому месту.
  • journal теперь индексирует имеющиеся значения полей для каждого поля. Это позволяет клиенту просмотреть имеющиеся значения при фильтрации. В соответствии с этим обновлены bash completion. journalctl получил новый параметр -F для просмотра имеющихся значений, которые принимает поле в базе журнала.
  • Большее количество сообщений сервисов теперь записываются в журнал как структурированные и распознаются по идентификатору.
  • Мини-сервисы timedated, localed, которые ранее предоставляли поддержку смены времени, локали и имени хоста только из графического окружения типа GNOME, теперь имеют и минималистичные (но весьма функциональные) консольные клиенты для управления. Возможно, теперь это самый приятный способ смены настроек из командной строки, в особенности потому, что в них присутствует полный список опций и они интегрированы с bash completion.
  • Новая утилита systemd-coredumpctl для получения списка и извлечения coredump-ов из журнала.
  • Теперь дистрибутив устанавливает README-файлы в /var/log/ и /etc/rc.d/init.d, которые поясняют, куда подевались журналы и скрипты инициализации. Автор надеется, что это поможет сориентироваться зашедшему в эти, теперь пустые, каталоги.
  • В gatewayd добавлено множество возможностей таких, как режим «follow» для режима немедленной синхронизации и фильтрации.
  • gatewayd/journalctl теперь поддерживают вывод типа HTML5/JSON Server-Sent-Events.
  • Логика режима совместимости с init-скриптами SysV теперь эвристически определяет поддержку скриптом ключевого слова «reload» и только при его наличии предоставляет возможность «systemctl reload».
  • Сервисы типа oneshot не могут использовать ExecReload=.
  • При запуске пользовательского сервиса (через systemd --user) переменная окружения $MANAGERPID устанавливается в PID systemd.
  • Посылка сигнала SIGRTMIN+24 пользовательскому экземпляру systemd приводит к его немедленной остановке.
  • В browse.html теперь доступны фильтрация и просмотр детальной информации для отдельных полей.
  • «systemctl status --follow» удалено, используйте «journal -u».
  • Опции journald.conf RuntimeMinSize=, PersistentMinSize= удалены как бесполезные при настройке.

>>> Подробности



Проверено: JB ()
Последнее исправление: Silent (всего исправлений: 6)
Ответ на: комментарий от AVL2

ну да, если желание контролировать и отслеживать состояние сервисов в корне неверно, то systemd излишне сложен.

Контролировать сервисы надо, особенно если это десктопная машинка и за ней сидит твоя девушка или твой дедушка.

Вопрос, что для сервера — останов сервиса — это задача, которую необходимо решать не перезапуском сервиса, а для начала определить, почему же он умер. Для индикации смерти сервиса хорошо подойдет любая система мониторинга, которая уведомит, кого надо.

Но поскольку Поттеринг тащит все в один комбайн, а не делает систему слабосвязанных самодостаточных компонентов с четко прописанными интерфейсами (что фактически и является настоящим «юникс-вей»), выборочно управлять жизненным циклом отдельных процессов/компонентов, или собрать необходимый набор правильных компонентов (или исключить лишние) не представляется возможным.

Поэтому и называю данную реализацию хороших идей убогой.

dr_dobermann
()
Ответ на: комментарий от dr_dobermann

сделать няньку для процессов...насколько это надо, например на сервере

Очень. На серверах часто запускаются программы с не совсем предсказуемым поведением. По моему опыту, предсказуемое поведение встречается реже (как минимум, падение таких не так часто заметно). И таки нужно уметь их перезапускать надёжно.

DonkeyHot ★★★★★
()
Ответ на: комментарий от dr_dobermann

решать не перезапуском сервиса, а для начала определить, почему же он умер

К тому времени меня бы уже уволили.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

На серверах часто запускаются программы с не совсем предсказуемым поведением.

часто

o_O

Binary ★★★★★
()
Ответ на: комментарий от DonkeyHot

я бы точно уволил дятла, бездумно перезапускающего сервис, вместо того, чтобы разобраться почему же он падает.

И не надо путать систему мониторинга и «бебиситтера над процессами» как это описывал Поттеринг.

dr_dobermann
()
Ответ на: комментарий от DonkeyHot

На серверах часто запускаются программы с не совсем предсказуемым поведением.

А за такое админа надо ссаными тряпками гнать, причем даже мимо техподдержки, бо и там с таким подходом можно бед натворить.

dr_dobermann
()
Ответ на: комментарий от dr_dobermann

На серверах часто запускаются программы с не совсем предсказуемым поведением.

А за такое админа надо ссаными тряпками гнать, причем даже мимо техподдержки, бо и там с таким подходом можно бед натворить.

Я бы тоже хотел жить в идеальном мире. И тоже бы чётко знал что такое хорошо, а что такое плохо.

Но вот ситуация - организация закупила программный комплекс. И в этом комплексе периодически (раз в день или реже) происходит сбой некоего сервиса. Точно определить в чем проблема нет возможности - лицензионные соглашение о не ковырянии в программе.

Фирма поставщик извещена о проблеме и сообщила что в течении месяца, или двух будет предоставлени багфикс релиз.

Прикажете остановить работу программного комплекса пока поставщик не исправит ошибку?

Ладно если фирма-покупатель коммерческая контора и просто будет терять деньги при простое. Но ведь это может быть и госконтора. И людей которые приняли решение о закупке могут посадить за «покупку неработающего непонятно чего»

anonymous
()
Ответ на: комментарий от dr_dobermann

как все-таки приятно что местные петросяны опять слили :-) каждый тред о системд доставляет баттхертом малограмотной школоты - шавки лают, корова идет...

anonymous
()
Ответ на: комментарий от anonymous

Кстати, на всякий случай, в RH6 upstart ВНЕЗАПНО! ;-)

А что, ты думаешь systemd уже созрел для энтерпрайза? Там такое говно мамонта порой встречается, что просто диву даёшься - просто жертва, приносимая на алтарь надёжности. Когда systemd стабилизируется и какое-то время потестируется - тогда уже будут его включать в RH. Но это ещё годы должны пройти, наверное.

anonymous
()
Ответ на: комментарий от anonymous

Но вот ситуация - организация закупила программный комплекс. И в этом комплексе периодически (раз в день или реже) происходит сбой некоего сервиса. Точно определить в чем проблема нет возможности - лицензионные соглашение о не ковырянии в программе.

Фирма поставщик извещена о проблеме и сообщила что в течении месяца, или двух будет предоставлени багфикс релиз.

Прикажете остановить работу программного комплекса пока поставщик не исправит ошибку?

Твоя организация приобретая ПО заключила договор с поставщиком и на основании этого договора осуществляется техподдержка. Естественно чем круче обязательства по поддержке - тем дороже она стоит. Сэкономил твой менеджер на техподдержке и SLA даёт месяц на разрешение критических проблем (проблема, которая угрожает остановкой бизнеса, как в твоём случае, считается критической) - то такой манагер ССЗБ, ведь идеального софта почему-то не бывает. Хотя, с учётом реалий, он скорее ЗБ для своего работодателя - схватит бонус за «экономию», а когда контора из-за единственного бага развалится - пойдёт рубить бабло в другой фирме.

anonymous
()
Ответ на: комментарий от tailgunner

systemd будет в RHEL 7

Возможно.. Какая разница.

anonymous
()
Ответ на: комментарий от sergv

2. Развитие чего? Что нового из _нужного_?

Попытки создать:
* Запуск сервисов по событиям (загрузка системы - только разновидность)

Запуск сервисов по событиям существовал всегда, и управлялся тем, кто заведует событиями. Cron запускает по времени, [x]inetd — при коннекте на сокет, браузер — при клике на ссылке, плеер — при нажатии на кнопку, Midnight Commander — по ентеру на файле, а init — при включении. И нет ни одной причины тянуть их все в один процесс.

* Защищенный от модификации журнал

Во-первых, его не нужно защищать. От кого? От того, кто проник на машину? Так если он уже проник на машину, то защищать поздно. Вы все, что, обкурились? Syslog — это унифицированный способ вывода для демонов, это printf для них такой. Он нужен для отладки, для анализа проблем, для сбора статистики, но уж совсем не для криптографии или защиты. Защищать сислог — это как защищать stdout хелловорлда.

Во-вторых, поинтеринг уже раза три заявлял, что сочинил мегакрутой защищенный журнал, и каждый раз его тыкали носом в грязь. В этот раз, чтобы не тыкнули, он даже не стал разглашать подробности, мол ковыряйтесь в исходниках сами. Такая вот надежная криптография, называется Security Through Obscurity. Реально единственная «защита» — это отправка копии сислога на другую машину. И любой сислог-демон это умеет уже кучу лет, только до леннарта это не доходит. Блин, да даже однострочный скрипт на баше защитит любой текстовый сислог надежнее, чем эта дурацкая поделка с журналом.

* Контроль доступа на этапе запуска (cgroups из коробки)

На самом деле cgroups — это отличный способ динамического управления приоритетами и ограничениями. Он позволяет на лету давать больший приоритет нужным процессам, ограничивать потребление памяти, увеличивая отзывчивость системы. И был даже демон, ulatencyd, который выполнял эту работу. К сожалению, systemd убил на корню всю идею.

Cgroups для systemd — это костыль, который леннарт прикрутил, потому что не придумал, как иначе стопать процессы, ведь он же гордо заявил, что баш-скрипты гавно, а оказалось, что каждый процесс стопается по-разному, и без баша это хрен опишешь. Никакого контроля это не дает. Процессы, которые стартуют от рута, могут легко прыгнуть в другой cgroup. А процессы, которые запускаются от собственного юзера, можно легко отследить по их же юзеру, и cgroups для них не нужен.

Правда, оказалось, что cgroups тоже не решает проблему, потому что «сервисы» бывают разные. Вот, например, сервис iptables, как cgroups поможет определить, запущен он или нет? А как на счет сервиса nvidia, который генерирует xorg.conf при загрузке? Процессов у него тоже нет, запустился, стопнулся и все, чем cgroups поможет? Поэтому леннарт начал прикручивать другие костыли...

anonymous
()
Ответ на: комментарий от plm

Решение есть давненько: cgroups - но его никто не торопится применить в sysv (хотя, наверное можно)

Нельзя - потеряется кросс-платформенность.

Cgroups — не решение, и вообще для этого не было предназначено. Использование cgroups для слежки за процессами — это костыль поттеринга. В sysv применено универсальное решение — каждый сервис точно знает, как управлять своими собственными процессами, и именно так ими и управляет. Это только леннарт мог подумать, что он самый умный и знает, как все должно работать.

anonymous
()
Ответ на: комментарий от sergv

Монтирование флэшки при втыкании.

Во-первых, это плохая идея. Не любую флешку надо монтировать при втыкании, там могла быть поврежденная файловая система, которая будет окончательно убита монтированием. Во-вторых, если уж так приспичило, это легко делается udev-ом + тем демоном, который собственно будет ее монтировать. Навскидку забавный способ

Чтение данных для авторизации с воткнутого токена.

Точно так же, udev сигналит тому, кто будет читать.

Переконфигурация сетевых служб при поднятии нового интерфейса...

Очевидно, их должна запускать служба, управляющая сетью. Может именно для этого изобрели /etc/network/if-up.d/?

Это -проблема поттерингожурнала. А вот необходимость контроля записи в него и контроля целостности признается как минимум авторами syslog-ng и Solar Designer.

Нет такой необходимости. А если бы и была, ее можно обеспечить только одним способом — транслированием журнала на другую машину. Любой syslogd это умеет, кроме поттеринговского. То, что понтеринг назвал «защитой», делается элементарным однострочником на баше, причем работать оно будет для любого текстового файла, и будет надежнее, чем изобретение поттеринга.

anonymous
()
Ответ на: комментарий от AptGet

давай поспорим, что ты не сможешь описать чем именно устарел sysvinit и какие фунцкии он дожен выполнять?


Можно я отвечу? 2 простые вещи навскидку:
a) надежное отслеживание состояния демонов
b) API для контроля демонов. Без system()/popen()/парсеров.

Для начала, отслеживание в systemd совершенно ненадежное (см. сообщения выше). Ну а вообще да, все верно, еще sysvinit не играет музыку, не качает торренты и не варит кофе. И это нормально, каждая программа должна выполнять одну задачу, но делать это хорошо. Sysvinit выполняет одну задачу — инициализацию системы, и с ней справляется отлично. Следить за тем, что в системе происходит после этого — не его работа.

В реальной жизни следить нужно не за тем, чтобы сервис был запущен, а за тем, чтобы он работал. Сервис может не только упасть, он может повиснуть, может перестать принимать входящие соединения, может начать жрать 400% CPU, да кучу всего. И если это произойдет, админ должен об этом узнать. Сервис ни в коем случае не должен быть автоматически перезапущен (например, бездумный перезапуск сервера базы данных может окончательно убить базу). Наоборот, система должна в лучшем случае послать уведомление админу и ждать.

Такова реальность. И systemd не решает тут ни одной проблемы. Он только делает вид, что собирается их когда-нибудь решить. А на практике Леннарт отказался даже отправку емейла в случае респавна делать. Хотя, наверное, это временно. Со временем почтовый сервер обязательно будет входить в состав systemd, вместе со встроенным клиентом обмена сообщениями, на случай если кому-то захочется початиться со встроенным в systemd искуственным интеллектом.

anonymous
()
Ответ на: комментарий от littlechris

Что мне здесь не нравится:
* PID то есть, то нет (хотя acpid — очень даже конкретный процесс)
* перевод часов назад по идее приведёт к заворачиванию куска лога

(говорят, перевод часов в systemd вызывает очистку лога, но мы не будем о грустном)

* элементарная фальсификация записей — насколько я понимаю при отсылании log entry через сокет любой клиент способен представиться любым другим клиентом и написать вообще что угодно.
* как следствие, надёжно отфильтровать записи, к примеру, касающиеся только конкретного сервиса, невозможно в принципе.

Да, все верно. Нет встроенной защиты от фальсификации, нет «надежного» фильтра, нет даже PID-а у некоторых процессов (хотя по просьбам фанбоев systemd в rsyslog была добавлена такая возможность). В классическом сислоге этого нет. И что? У вас демон ssh часто выдает себя за cron, а демон acpid прикидывается rsyslog-ом? Нет? Тогда зачем это? Какой смысл защищать себя от собственноручно запущенных программ?

Есть хоть одна реальная причина, для которой «надежный» фильтр был бы нужен? Вы что, боитесь, что хакер взломает вашу машину чтобы насрать вам в сислог? Пора перестать вестись на рекламные лозунги леннарта, проталкивающего свое детище, и начать уже самим думать головой.

anonymous
()
Ответ на: комментарий от ak375291

Понимаешь, автор хочет создать лошадь, которая будет пахать землю, разносить кофе, танцевать самбу и подрабатывать проституткой. Беда одна: эта лошадь будет хреново пахать землю и танцевать, да и проститутка из неё никакая.

Наиболее полное, точное и адекватное описание всей ситуации с systemd.

Увы, беда не в этом. Автор старательно рекламирует свою клячу как самый лучший в мире трактор, стюардессу, танцовщицу и проститутку. И агитирует всех выбросить привычные им тракторы, отказаться от услуг кафе, развестись с женой и взамен взять его лошадь. И беда в том, что несмотря на всю абсурдность, ему верят.

Леннарт — гениальный маркетолог. Он даже круче, чем Билл Гейтс. Тот когда-то вышел на рынок благодаря тому, что предлагал то, чего ни у кого раньше не было. Да, первые поделки Гейтса тоже дико глючили, и на них все плевались и плюются до сих пор, но тогда им не было аналогов. Он, практически создал рынок программного обеспечения. Леннарт пошел еще дальше, он умудрился всучить свою лошадь даже тем, у кого были в руках более удобные и надежные инструменты.

anonymous
()
Ответ на: комментарий от chinarulezzz

Когда Линус говорит что в ядро он не возьмёт шедулер когда есть CFS, и когда нет ответа на вопрос какой шедулер является лучшим

Ответ заключается в том, что для разных применений лучшим является тот или другой. Искать «самый лучший вообще» — это какое-то детство в жопе, извините.

geekless ★★
()
Ответ на: комментарий от anonymous

Есть опция позволяющая задать поведение.

На стадии компиляции, а не запуска.

geekless ★★
()
Ответ на: комментарий от anonymous

Монтирование флэшки при втыкании.

Во-первых, это плохая идея.

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

Т.е. если запуск при старте системы и запуск при внешнем событии на работающей системе мало чем отличаются, то не логично-ли вынести это в отдельную универсальную для обоих случаев службу?

(Да, его реализация безумна.)

Это -проблема поттерингожурнала. А вот необходимость контроля записи в него и контроля целостности признается как минимум авторами syslog-ng и Solar Designer.

Нет такой необходимости.

Есть. Погугли про Solar Designer-а, syslog и контроль PID/UID/GID.

(Опять-таки, поттерингожурнал - безумие.)

sergv
() автор топика
Ответ на: комментарий от sergv

Т.е. если запуск при старте системы и запуск при внешнем событии на работающей системе мало чем отличаются, то не логично-ли вынести это в отдельную универсальную для обоих случаев службу?

Нет, не логично. :) Абсолютно все запуски в юниксах ничем не отличаются. Все они — это fork+exec с небольшими вариациями. Запуск программы Enter-ом в mc тоже ничем не отличается от запуска этой же программы по cron-у. Но это же не значит, что надо встроить cron в mc или mc в крон. :)

Есть. Погугли про Solar Designer-а, syslog и контроль PID/UID/GID.

В гугле первой ссылкой — эта тема. :) А в чем суть? Для чего это? Если просто забавная фича, то почему бы и нет. Но практического применения для нее я не вижу.

anonymous
()
Ответ на: комментарий от anonymous

Но вот ситуация - организация закупила программный комплекс. И в этом комплексе периодически (раз в день или реже) происходит сбой некоего сервиса. Точно определить в чем проблема нет возможности - лицензионные соглашение о не ковырянии в программе.

А если у тебя базулька там падает куда данные пишутся? Не боишься все их потерять при некорректном рестарте? Тебе этот мониторинг от системд вообще никак не поможет.

anonymous
()
Ответ на: комментарий от anonymous

А в чем суть? Для чего это?

Защита от подделки записей в системном журнале. Крайне маловероятно, конечно, что враг не только тихо погасит сервис, а еще и PID его-же получит для своей софтины, дабы админу, разбирающемуся со взломом, мозг запарить.

Но - для параноиков надо, да. ;-)

sergv
() автор топика
Ответ на: комментарий от anonymous

Увы, беда не в этом. Автор старательно рекламирует свою клячу как самый лучший в мире трактор, стюардессу, танцовщицу и проститутку. И агитирует всех выбросить привычные им тракторы, отказаться от услуг кафе, развестись с женой и взамен взять его лошадь. И беда в том, что несмотря на всю абсурдность, ему верят.

Леннарт — гениальный маркетолог. Он даже круче, чем Билл Гейтс. Тот когда-то вышел на рынок благодаря тому, что предлагал то, чего ни у кого раньше не было. Да, первые поделки Гейтса тоже дико глючили, и на них все плевались и плюются до сих пор, но тогда им не было аналогов. Он, практически создал рынок программного обеспечения. Леннарт пошел еще дальше, он умудрился всучить свою лошадь даже тем, у кого были в руках более удобные и надежные инструменты.

К большому сожалению, Вы совершенно правы. Талантище. Но не в программировании. От него так и разит какой-то нездоровой харизмой.

ak375291
()
Ответ на: комментарий от ak375291

От него так и разит какой-то нездоровой харизмой.

Он-же автор мысли о том, что фря, соляра и иже с ними должны умереть, и только линукс - рулит.

Религиозное поклонение, не?

sergv
() автор топика
Ответ на: комментарий от sergv

Он-же автор мысли о том, что фря, соляра и иже с ними должны умереть, и только линукс - рулит.

Религиозное поклонение, не?

Да Вы что! Не знал. Все, оказывается, гораздо хуже. :(

ak375291
()
Ответ на: комментарий от anonymous

Cgroups — не решение, и вообще для этого не было предназначено. Использование cgroups для слежки за процессами — это костыль поттеринга. В sysv применено универсальное решение — каждый сервис точно знает, как управлять своими собственными процессами, и именно так ими и управляет. Это только леннарт мог подумать, что он самый умный и знает, как все должно работать.

не-не-не, cgroups это решение в случае когда надо добить всё, если сам процесс не справился, а наплодил потомков, т.е. такое оружие на последнем этапе, если всё остальное не сработало.

qnikst ★★★★★
()
Ответ на: комментарий от ak375291

BSD сдерживает развитие СПО

Да, я считаю, что BSD уже особо не важен, и я думаю, что эта подразумеваемая совместимость с BSD - бремя, которое сдерживает нас и почти ничего не дает. Я не считаю, что они (BSD-системы) никому не нужны: все таки есть люди, которые их используют. Просто думаю, не в наших интересах тратить силы на поддержку, если мы хотим, чтобы Linux повсеместно вошел в мейнстрим (а не только серверы и ограниченные платформы, как Android)...

sergv
() автор топика
Ответ на: комментарий от vasily_pupkin

ладно пофиг на логи и прочие вещи. Ты мне лучше расскажи знаешь ли ты зачем systemd раз в день tmp.d файлы перевыполняет?

qnikst ★★★★★
()
Ответ на: комментарий от dr_dobermann

Вопрос, что для сервера — останов сервиса — это задача, которую необходимо решать не перезапуском сервиса, а для начала определить, почему же он умер.

Прекрасно. Не останавливайся на достигнутом. Прежде, чем запускать программу, необходимо разобраться, а возможна ли ситуация, когда он работает некорректно.

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

нет привычки с анонимами беседовать, но на редкость хороший вопрос.

Но вот ситуация - организация закупила программный комплекс.

Бывает и такое. Если не смог пробить и затвердить политику, по неизменности ит-ландшафта без необходимого тестирования, включающего некороткую опытно-промышленную эксплуатацию под полной нагрузкой (даже это иногда не помогает, хотя бы по причинам невозможности загрузить процедурой закрытия года систему, например в июле), то тут ССЗБ.

И людей которые приняли решение о закупке могут посадить за «покупку неработающего непонятно чего»

По поводу этого у тебя два пути — (1) тихо перезапускать, если люди тебе не безразличны, либо (2) сказать что все именно так и есть и наказать клоунов, которые тебе попытались на голову надеть какую-то херню. Хотя если есть шанс, что посадят — у тебя остается только первый вариант.

Но в первом случае это можно сделать в автоматическом режиме, если ты все последствия перезапуска себе представляешь или их нет. А если они таки есть — например надо что-то чистить, то тут нужен скриптик, который весь мусор перед запуском почистит. То есть тут Леннартовский подход уже не работает.

А если ты последствия не знаешь, то каждый раз придется разбираться, что же еще сломалось и можно ли перезапуск сделать.

dr_dobermann
()
Ответ на: комментарий от vasily_pupkin

так.. при загрузке выполняются все действия описанные в tmp.d файлах, в дополнение к этому эти действия перевыполняются раз в день [1], вопрос, какая на то причина, или это какой-то костыль?

[1] тут для продолжения нездоровой дискуссии можно вспомнить про reimplementing cron.

qnikst ★★★★★
()
Ответ на: комментарий от AlexM

Нет. Основная /проблема/ в том, чтобы этим бебиситтером был именно pid=1

Базовый минимальный уровень должен обеспечивать pid=1.

Нельзя отдавать обеспечение минимума каждому сервису в свои руки.

AVL2 ★★★★★
()
Ответ на: комментарий от vasily_pupkin

да и я спрашиваю, не потому, что хочу сказать, что SD отстой, а т.к. мне действительно интересно зачем это надо. А т.к. про дизайн SD у Поттеринга не почитаешь, то спрашивать у тех, кто пользуется приходится.

qnikst ★★★★★
()
Ответ на: комментарий от AVL2

supervision service не обязать быть pid-1, хотя желательно, чтобы он был родителем сервисов.

SystemD помимо опций supervision сервиса выполняет ещё достаточно много функций причем не модульно, т.е. заменить какой-то компонент на тот, который работает на конкретной задаче лучше не представляется возможным, плюс потенциально опасные вещи такие как клиент dbus находятся в pid-1.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Ну, оно просто чистит/создает временные каталоги в соответствии с политикой. Оно настраивается в соотв. местах. Обычные иниты этим тоже занимались (в плане чистки/создания), тут он таймер запилил

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

supervision service не обязать быть pid-1, хотя желательно, чтобы он был родителем сервисов.

Что бы он не был pid=1, нужно будет в pid=1 запилить соответствующий механизм оповещений через какой-нибудь IPC.

И я не понимаю, почему столько внимания уделяется тому, что напихано в pid1

достаточно много функций причем не модульно

Это верно, но давай ты тут напишешь, что по твоему мнению таковым является

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

вопрос, есть ли какая-нибудь причина, зачем это делается и по таймеру, а не только при загрузке/установке сервиса? если ли в этом необходимость?

qnikst ★★★★★
()
Ответ на: комментарий от vasily_pupkin

И я не понимаю, почему столько внимания уделяется тому, что напихано в pid1

потому, то pid-1 не должен падать никогда.

Это верно, но давай ты тут напишешь, что по твоему мнению таковым является

это бесполезно :) слишком разные понятия о модульности и том как должна работать система. мои аргументы ты не примешь, как и я твои.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

есть ли какая-нибудь причина, зачем это делается и по таймеру

Понятия не имею. Может быть в федоре была какая-то такая фича. А может быть потому что может. В целом это представляется милой фичей, но на исключительно необходимую оно не тянет, да. Впрочем, тут надо уточнить, в данной плоскости это не замена, а рекомендации чистильщику.

А вот чистильщик уже запускается по таймеру, но его можно выкинуть.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

потому, то pid-1 не должен падать никогда.

Я думаю ты хотел сказать - не должен никогда завершаться? Или должен всегда исполнять свой пид1овский долг? :]

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Понятия не имею. Может быть в федоре была какая-то такая фича. А может быть потому что может. В целом это представляется милой фичей, но на исключительно необходимую оно не тянет, да. Впрочем, тут надо уточнить, в данной плоскости это не замена, а рекомендации чистильщику.

ну так просто она выглядит совершенно не нужной. а её правильная автоматическая реализация неочевидна. Возникает вопрос, а нужна ли эта фича в принципе.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

В плане централизации сведений о временных файлах - вполне себе нужная штука. Использует её отдельная утилита из поставки systemd, со своим юнитом. Который соответственно можно отключить/заменить. Можно написать свой костыль для крона который будет использовать эти сведения, например

vasily_pupkin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.