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)
Ответ на: комментарий от qnikst

я про квалификацию в программировании

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

x:5:respawn

это здесь, чтобы перезапустить один сервис, нужно передёргивать весь runlevel? а, понял — killall thin его убьёт, а respawn перезапустит. точнее sudo killall. очень удобно, да.

олсо в убунте inittab как раз и нет. так что или инитскрипты или конфиг.

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

«there is no choice here: logging and log rotation management must be done by the same tool».

А тебя кто-то заставляет использовать «the same tool»?

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

сравниваются разные по функционалу вещи

я вижу. скрипта с выкинутыми наворотами не нашёл. но даже если выкинуть xconsole- и freebsd-related код, получается всё равно в разы больше текста. взять хотя бы explicit логгинг.

не запускаемся ли мы под GNU/kFreeBSD

нет systemd — нет проблемы :)

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

Я тоже таки щетаю. Это прекрасно, что наши щетания совпадают !

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

в убунте как я понимаю ни на что кроме апстарта смотреть вообще не стоит, т.к. это такой предок systemd, к которому вопросов ещё больше, т.к. помимо комбайна у апстарта ещё и реализация подкачала.

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

у апстарта ещё и реализация подкачала.

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

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

взять хотя бы explicit логгинг.

Ну, повторюсь, у меня сислог запускается так:

start()
{
        msg_starting $«system logger»
        start_daemon --pidfile «$PIDFILE» --lockfile «$LOCKFILE» --no-announce — syslogd $SYSLOGD_OPTIONS
        RETVAL=$?
        return $RETVAL
}

а sshd - вот так:

start()
{
        is_yes «$NETWORKING» || return 0
        gen_host_keys
        start_daemon --pidfile «$PIDFILE» --lockfile «$LOCKFILE» --expect-user root — $PROCESSNAME $EXTRAOPTIONS
        RETVAL=$?
        return $RETVAL
}
Что характерно, оба два этих случая влёгкую сворачиваются до ини-стайл определения «параметров» с последующим выполнением совершенно стандартных процедур. Просто, э-э-э, никому особенно не надо.

При этом, я вполне допускаю, что задача «ускорения баша» и хитроумных скриптов на нём - это задача, грубо говоря, нерешаемая. Поэтому DSL (может, даже, компилируемый DSL) - возможен и полезен. Но это не отменяет необходимости a) продумывать цели, b) выбирать средства для их достижения и c) анализировать промежуточные результаты. Пока деятельность Поттеринга не производит впечатление особо продуманной. Предложения типа «а давайте запретим /usr на отдельном разделе, у меня не получается корректно файлуху монтировать» или приведённые выше файлики запуска SSHD'шных потрохов наводят на мысль, что чувак в принципе неспособен к рефлексии.

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

Поэтому DSL (может, даже, компилируемый DSL) - возможен и полезен.

Это же думать надо, проектировать. А поцеринг умеет только на Си куячить.

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

тут ещё слухи ходили, что оно вообще сдохло, не подтвердилось чтоли? ну ни кто ж не спорит, что у системд, есть немало удачных идей.

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

принимать оппонента как серьёзного человека уже нельзя

Если не пытаться понять, что он имел ввиду. Вопреки тому, что вам показалось, я *нигде* не говорил, что systemd - панацея, решает все проблемы сбойных сервисов, etc. Я всего лишь пытаюсь понять, что вас в нём так раздражает, и с удивлением обнаруживаю, что большая часть упоминаемых раздражителей не в лучшем виде присутствуют и в эталонном sysvinit-е.

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

оба два этих случая влёгкую сворачиваются

окей. почаще бы так.

Пока деятельность Поттеринга не производит впечатление особо продуманной

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

«а давайте запретим /usr на отдельном разделе, у меня не получается корректно файлуху монтировать»

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

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

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

А если он сам в этом не признается, то ничего и не было? Ссылка на обсуждение факапа с /usr уже была.

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

ЕМНИП, Шаттлворт особо отметил, что переезда на systemd не будет ещё долго.

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

если он сам в этом не признается, то ничего и не было?

конечно. а как вы думали?

Ссылка на обсуждение факапа с /usr уже была.

на этот счёт хорошо прошёлся plm:

Не так давно, в конце августа, участники коммьюнити Debian с удивлением обнаружили, что и без systemd /usr на отдельном разделе поломан, и теперь обуждают, как с этим жить дальше. Впереди еще много открытий.

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

если он сам в этом не признается, то ничего и не было?

конечно. а как вы думали?

А мы не только поцеринга слушаем.

на этот счёт хорошо прошёлся plm:

Мнение толстого рашен федораста не имеет ровно никакой ценности.

теперь обуждают, как с этим жить дальше. Впереди еще много открытий.

В обсуждении по ссылке не предлагают объединить / и /usr.

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

Вообще это не нужно, т.к. shutdown и так стопнет сессии. Но если очень хочется, то делается сервис shutdown-ssh-sessions.service, туда пихается в Install WantedBy=shutdown.target и делается enable. Если очень очень хочется что бы это запускал имеенно sshd при останове (хотя это полный бред), то пихается ExecStopPost=/usr/bin/systemctl start shutdown-ssh-sessions.service, а в shutdown-ssh-sessions.service добавляется Requisite=shutdown.target

Хм... ExecStopPost с минусом, наверное? А, или минус тут не работает... Хотя, пожалуй, он все равно не запустится, ведь shutdown.target в тот момент будет еще waiting. Но вообще мысль интересная. Эх, проверить негде...

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

Для этого и придумали LSB (start_daemon, log_success_msg, ...). Но на самом деле обычно всем пофиг. Initscript пишется один раз мейнтейнером при добавлении пакета в дистрибутив. И с тех пор он обычно не меняется... Пока кому-то не взбредет в голову заменить основную init-систему дистрибутива.

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

А мы не только поцеринга слушаем.

бабулек на лавочке у подъезда?

Мнение толстого рашен федораста

  • выбираем произвольный признак клеймления (гомофоб/гомосек/гномовод/кедовод/линуксовод/виндузятник/белый/чёрный/очкарик/лысый/русский/чурка/пиндос/тысячи их)
  • клеймим
  • ПРОФИТ — мнение заклеймлённого не имеет никакого значения!

В обсуждении по ссылке не предлагают объединить / и /usr.

кажется, я понял. Типичная логическая ошибка. После — не значит вследствие, слыхали, может? Впрочем, если очень хочется — то значит. Понимаю.

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

А мы не только поцеринга слушаем.

бабулек на лавочке у подъезда?

В пределах их компетенции - да, конечно.

мнение заклеймлённого не имеет никакого значения!

Такое отношение к своему мнению заклеймленный честно заслужил.

После — не значит вследствие, слыхали, может?

Слыхал, да. Это имеет какое-то отношение к тому, что Дебиан не предполагает объединять / и /usr, а в сообществе Федоры есть мнение о том, что объединение было ошибкой?

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

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

Конечно, не составит.

http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Причём, замечу, в списке софта, который м-р Поттеринг привёл как пример «сломанного», добрые две трети - это то, что они с м-ром Сиверсом и нах..рили в ходе своего юдевно-пульсаудишного марафона.

Собственно, проблема здесь проста, и яйца сломанного не стоит. С одной стороны, от Поттеринга потребовали (или он сам так решил), чтобы система загружалась параллельно-параллельно, перпендикулярно-перпендикулярно.

С другой, очевидно, что при наличии в /etc/fstab множества автоматически монтируемых файловых систем с нетривиальным fsck в жизни инита возникает, скажем так, особенный момент. Причём, файловые системы эти - не обязательно /usr, просто на /usr легче всего наступить таким горячим парням, как Леннарт. И в этот момент параллельность - она, э-э-э, серпом... неуместна.

Особенность момента заключается в том, что для fsck требуется наличие собственно блочного устройства и работоспособных утилит по проверке, а также отсутствие других пользователей этих файловых систем. За появление блочного устройства в /dev ответственнен udev с его потенциально сколь угодно сложными правилами. Маслица в огонь добавляет необходимость предварительных приседаний с DM/EVMS/LVM & Co, но эти, по крайней мере, ограничены в наборе задач и средств.

А вот бездумное выполнение UDEV'ных правил действительно может вылиться в принципиально неизбегаемый кошмар на загрузке. И тогда, действительно, в процесс fsck может вклиниться и CUPS, и чёрт с рогами (пользователи фряхи в этом месте ехидно скалятся и вспоминают демотиваторы с Туксом и Демоном в главных ролях).

То есть, становится очевидно, что разборки с файловыми системами необходимо проводить в режиме, когда udev, с одной стороны, уже есть, а с другой - его функциональность ограничена ровно приведением в чувство того блочного устройства, консистентность файлухи на котором мы собираемся проверить. А все купсы и прочие попёрдывания альсы нужно откладывать до тех пор, пока у нас не отработает mount -a.

Собственно говоря, проблема эта неспецифична именно для systemd, просто в «классическом» случае она нивелируется тем, что rc.sysinit пишут вменяемые мэйнтэйнеры, а разбивку на тома при установке системы проводят вменяемые админы. Не «слава роботам!», а, тыкскыть, коммон сенс и жизненный опыт.

Однако, вместо того, чтобы изобрести для udev режим инициализации только требуемого device node (а юдев, напомню, сейчас уже в дереве системд) и положиться на то, что администратор системы не захочет, чтобы при нахождении очередного блочного устройства в колонки проигрывались оргастические звуки*, Леннарт (с Кэем) предпочли объявить /usr пережитком тёмного прошлого.

* отдельная тема - это «/usr по сети». Понятное дело, что если поднимать сеть при помощи NetworkManager'а, то тут без вариантов - NM чуть менее, чем полностью лежит в /usr. Но, на минуточку, осознаём, что гнездо у NM - на gnome.org, и понимаем, что его пишут в соседней от Леннарта комнате. «От этих космобольцев жди одних неприятностей».

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

в сообществе Федоры есть мнение о том, что объединение было ошибкой

И Щьто? вот если бы начали разъединять обратно — тогда было бы о чём говорить.

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

Леннарт (с Кэем) предпочли объявить /usr пережитком тёмного прошлого

ссылки на «объявляем пережитком, чтобы udev c альсой работали; чтоб вы сдощасливой отладки, Леннарт и Кей» от вас я тоже не дождусь?

проблема эта неспецифична именно для systemd

Blame CanadaLennart! (2 раза)

вместо того, чтобы изобрести для udev режим инициализации только требуемого device node

его только что изобрели лично вы. сделали, так сказать, работу за этих недоумков. осталась сущая безделица — реализовать.

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

В systemd им тоже не место?

да, не место.

Но ведь они там есть. И в намного большем количестве. Получается, systemd еще хуже?

Чтобы написать инитскрипт, с нуля нужно раскурить гораздо больше информации, чем по SD. сначала LSB, затем шелл (ну его все знают, ладно), затем техники камлаbest practices написания как инитскриптов вообще, так и в конкретном дистре.

А в реальной жизни:
* Для себя: в rc.local дописывается одна строка
* Для себя, но круче:

#!/bin/bash
case "$1" in
    start) /usr/bin/myserviced ;;
    stop) killall myserviced ;;
    restart|reload) $0 stop; $0 start ;;
    *) echo $"Usage: $0 {start|stop|restart|reload}"; exit 1 ;;
esac

* Для пакета, по-быстрому: делаем ls -la --sort=size /etc/init.d/, смотрим самые маленькие, и пишем свой по образу и подобию
* Для пакета, по-правильному (мейнтейнер): Если ты — мейнтейнер, то баш ты, вероятно, уже знаешь, иначе какой из тебя мейнтейнер. :) А тогда надо просмотреть только несколько примеров и подумать головой. Если ты умный, и знаешь про LSB, то можешь прочитать LSB «Init Script Functions». Если не такой умный, то написать скрипт просто по примерам.

И пофиг, какая там init-система и как она работает. А поскольку это — баш, то можно не бояться, что через пол года операторы устареют, исчезнут или поменяют формат. Поэтому initscripts обычно пишутся один раз, при добавлении пакета в дистрибутив, и после этого не меняются, пока не изменится init-система.

С systemd все хуже. Быстрый скрипт по примерам там не написать, потому что знание баша не поможет, а опций несколько сотен и ведут они себя очень по-разному. Придется так или иначе прочитать минимум пол сотни страниц документации и понять основные принципы работы systemd. Либо, как ты и написал, «preg_replaceом заменить путь к бинарнику и чинить симптоматически; это симптом профнепригодности и в итоге всё равно приводит к отстреленной ноге». Плюс постоянно следить за обновлениями в systemd, меняя свой скрипт вместе с ними.

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

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

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

Хватит нести бред про статический анализ декларативных конфигов, завтра в школу же...

так а где они используются в мейнстриме?

Ты не поверишь! В RHEL (может и в Debian, не знаю). Более того, именно там я ими и пользуюсь.

для RH (условно, там upstart и никого нанимать не нужно)

Да ты специалист по RHEL, я вижу... К твоему сведению, upstart там только запускает initscripts, а дальше загрузку проводят они. И слава богу, надеюсь и systemd там закончит в том же качестве, если вообще закончит.

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

Про devops слышал? Только больной даст колбасеру на PHP рулить деплоем в продакшон. Понятно всё с тобой, короче.

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

Ты вообще знаеш, что означает слово boilerplate?

надцать батников, различающихся только именем и путём к бинарнику. сплошь и рядом такое.

В systemd вот как раз так и есть же. Только там не батники, а ini-шки. Зато инитскрипты, как видно из примеров ранее, код очень сильно отличается.

pidfiles

они хрупкие. стёр pidfile — и всё, процесс потерян для инитскрипта

Что ж делать-то? Вон, в systemd вместо них cgroups, стёр изменил ее, и всё, процесс потерян для systemd. Интересно, он его при этом сразу перезапустит? Или как он на это отреагирует?

ulimit-ы в initscript-ах тоже всегда были из коробки

и кто ими пользовался?

Все, кому они нужны, /etc/security/limits.conf же есть из коробки. Ты думаешь, леннарт эти лимиты изобрел, что-ли? Ему ткнули, что раньше были лимиты, а в systemd их нет, он их и скопипастил. Зачем пользоваться готовыми инструментами, если можно изобрести свой велосипед, а потом искать в нём ошибки. Кстати, помнится, в systemd эти лимиты иногда не работали, не знаю, починили это уже, или назвали фичей...

cgroups в initsctipt-ах точно так же есть из коробки

и кто ими пользуется «искаропки»? openrc и его полтора разработчика?

Причем тут openrc? Ты знаешь, что такое cgroups и как они управляются? Ты думаешь, ими нельзя управлять из баша? Один из первых в мире пользователей cgroups — вот этот bash-скрипт (кстати, посмотри кто автор).

Boilerplate по определению не может быть в обработке краевых случаев.

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

Тогда это не краевые случаи. Либо мы понимаем разные вещи под словом «краевые».

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

Оно везде так. В том числе и в systemd. Там тоже можно написать неправильно, а потом обнаружить, что на некоторых машинах загрузка тупо виснет (вот, у меня виснет, уже не первый день ищем, почему). Но есть разница: чтобы найти ошибку в initscripts, надо знать баш, а чтобы найти ошибку в юните надо знать systemd. А теперь скажи, что узнать проще?

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

Можно мне раскрыть тему про отдельный /usr и /usr по сети?

Отдельным / c /bin,/sbin лично я пользовался для того, что бы все остальное держать на LVM. В конце-концов сдался и переехал на initramfs. Но вот зачем отдельный /usr по сети может быть нужен - мне сложно предположить

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

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

О, не дочитал до сюда. Да, ты правильно понял мысль.

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

стёр pidfile — и всё, процесс потерян для инитскрипта

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

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

Это будет худший вариант из возможных )

Да а чего так? Через года три его основу допилят до состояния, что он не будет сегфолтиться и течь. Или о чем тут речь?

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

Для этого и придумали LSB (start_daemon, log_success_msg, ...).

LSB это хорошо, но, к сожалению, действительно всем пофиг. И когда хочется обойтись без мантейнера, приходится решать кучу идиотских вопросов. Впрочем, едва ли тут systemd сделает погоду. Как показывает практика, дистростроители типа opensuse и RH все равно умудрятся выпустить ваз, даже на линии бмв

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

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

Будет косой cherry-picked systemd в легаси режиме, который запускает те же самые адские простыни, только асинхронно. Я такое в опенсузе видел, сру кирпичами

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

Будет косой cherry-picked systemd в легаси режиме, который запускает те же самые адские простыни, только асинхронно. Я такое в опенсузе видел, сру кирпичами

А я вот надеюсь, что серийно, как сейчас апстарт. И чего плохого? Хотя бы с идиотскими рейсами не придется бороться, в отличие от серверов на абанте (знаю, ссзб).

anonymous
()
Ответ на: комментарий от geekless
$ pacman -Ql openssh | cut -d' ' -f2 | egrep '^/usr/lib/systemd/.*[^/]$' | xargs grep ''
[...]

Ага, спасибо. Тут все немного иначе, не так, как мы пытались сделать. Правда, инитскрипт еще перегенерировал ключи если файл был, но пустой. Юнит так не умеет, но зато он использует опцию -A, в непоследних версиях ssh ее не было.

PS: блин, стоило отвернуться, и нафлудили 3 страницы. Это — заговор! Вы пытаетесь добраться до тыщи сообщений и избавиться от анонимусов!

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

Не, я про другое. Тут пишут будто sysvinit сотоварищи совершенен и якобы совершенно необходим Вообще Всем, и тем более — Обычным Пользователям. Если это действительно так, то логично ожидать, что существует изрядная очередь желающих поддерживать инитскрипты, если не во всех дистрах, то, как минимум, в мейнстримных. Иными словами, знамя не успеет долететь до земли, как его подхватят. Следовательно, беспокоится не о чем.

Увы, это не так. Во-первых, инитскрипты — это не юниты. У них синтаксис не меняется каждые пол года, и они не требуют почти никакой поддержки. Во-вторых, да, желающих их писать много, только их не принимают. Пишешь багрепорт с готовым приаттаченым скриптом, а тебе отвечают «initscripts are deprecated, rejected, wontfix». И всё.

Так что да, есть о чём беспокоиться. Если б беспокоиться было не о чем, что б мы тут тогда обсуждали...

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

Можно ли бебиситтера выпилить из системД?

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

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

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

Винда, сцука, быстрее стартует на том же железе

Только ее потом невозможно юзать некоторое время после старта. :)

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

Ищи сторонников, приводи их в дебиан или генту (у них, вроде, самая модульная система запуска), предлагай патчи. Лишний качественный конкурент systemd не помешает. :)

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

Основная идея автора: то, что любой logd сервис [...] может являться точкой отказа в сложной системе

И именно тут его главная ошибка. Syslog не может быть точкой отказа потому, что это — не критический сервис, и он никогда им не был. Это просто единая куча, в которую демоны могут сваливать свой протокол. Если сислог выключили (например, на read-only файловой системе) — ни одно приложение этого не заметит.

В реальной жизни задача сислога очень проста: демонам надо куда-то вести протокол, сбрасывать отладочную информацию, статистику всякую и т.д. Вот это «куда-то» — это и есть сислог. Для того, чтобы каждый демон не создавал собственный файловый лог, сислог заменяет для них printf. И он такой же простой, как printf.

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

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

ссылки на «объявляем пережитком...» от вас я тоже не дождусь?

(недоуменно) Вы читать умеете? Ну, вот и читайте, читайте, всё написано уже. "...Going forward ...we now just expect /usr to be pre-mounted from inside the initramfs, to be available before 'init' starts..."

Blame CanadaLennart! (2 раза)

По ходу, всё-таки не умеете. Или не хотите.

его только что изобрели лично вы.

Пойду запатентую, ага.

На самом деле, если бы Вы потрудились понять, как это всё сейчас работает (или ожидается, что работает) у Леннарта и Co, то Вы бы поняли, что они тоже, хм, изобрели нечто подобное. Правда, их решение предполагает, что в initramfs втащено всё, что потребно для mount -a (и что раньше могло преспокойно жить в /). Не вопрос, копаться в initramfs, случись чего - оно удобно, да.

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

Но вот зачем отдельный /usr по сети может быть нужен - мне сложно предположить

LTSP, например. Более того, даже Леннарт не отрицает такой потребности. Только в его решении basesystem, достаточный для приведения системы в чувство, лежит в initramfs. Что доставляет в случае возникновения любых проблем на этом этапе.

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

вот простой и понятный https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/... , который использует lsb-functions

Он их неправильно использует. В LSB для запуска стандартизирован start_daemon, а тут используется дебиановый/убунтовый start-stop-daemon. Вероятно, автор просто не разбирался слишком глубоко, и написал как смог.

а вот сложный и непонятный https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/...

Действительно, вроде такой короткий, а ведь фиг разберешься. Догадаться, что он делает, еще можно. Но это не поможет, потому что все равно не понятно, как оно работает и что нужно изменить. Например: он его перезапускает при падении, что-ли? Или вообще всегда перезапускает, вне зависимости от exit code? А каким образом он стопает приложение? А как мне вписать свою команду для остановки? А если у меня лог складывается в mysql, то как мне сделать, чтобы он стопался не позже, чем стопнется mysql? Ответ на любой из этих вопросов тривиален для инитскрипта и требует длительного гугления либо копания в исходниках в случае upstart.

Плюс у него тот же недостаток, что и у systemd — для того, чтобы написать upstart-скрипт, нужно прочитать кучу документации, либо копаться в исходниках. Причем после того, как ты его напишешь, эти знания тебе больше никогда не понадобятся (если только в синтаксисе что-то не изменится и твой скрипт не перестанет работать, что особенно вероятно в случае systemd). Ты просто тратишь свое время/деньги впустую.

Для того, чтобы написать initscript, надо знать только баш, больше ничего. А баш — это не только то, что почти все знают, но еще и то, что полезно в обычной повседневной работе. Затраты времени на изучение баша экономят тебе время/деньги в будущем.

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

Т.е. это вот ExecStart'ы полученные в эмердженси, после того job-list?

Не, это вообще все ExecStart-ы полученные командой:

for service in $(systemctl --all --no-legend | awk «{print \$1}»); do systemctl --no-pager show -p Id -p ExecStart $service; done

Тогда давай уточним [...]

http://pastebin.com/Acht5sQf (из emergency после подвисания)

OnFailure=emergency.target

Это в default.target было дописано мной, чтобы при подвисании загрузиться в emergency и снять все остальные команды.

Еще идеи? В systemd нет какой-нибудь хитрой опции, которая бы позволила узнать, что подвисает?

Запасной вариант - бутнуться с systemd.confirm_spawn=yes в cmdline, если совсем будет непонятно что

Эта опция дико глючит. Иногда запрос не появляется, пока не нажмешь enter. Иногда не появляется вообще и о том, что запрос вообще был, я узнаю по «confirmation request timed out, assuming positive answer». Но после того как они все были про-yes-аны, а часть запросов таймаутнулись, система загрузилась.

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

вроде такой короткий, а ведь фиг разберешься

а давайте вы почитаете man 5 init (из upstart), а я не буду оттуда ничего копипастить? там полсотни строк.

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

проверить это не велика сложность. А если там живёт тот же процесс с теми же аргументами, то это вообще странность.

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

Еще идеи? В systemd не какой-нибудь хитрой опции, которая бы позволила узнать, что подвисает?

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

Возвращай default.target в первозданный вид, как в поставке

rm -v /etc/systemd/system/default.target

Добавляй пару юнитов

cat /etc/systemd/system/boot-watchdog.target 
[Unit]
Description=Dump info on failure
OnFailure=boot-watchdog.service
JobTimeoutSec=40
After=default.target
DefaultDependencies=false
Requires=default.target

[Install]
WantedBy=default.target
cat /etc/systemd/system/boot-watchdog.service 
[Unit]
Description=Dump jobs to logs on boot-watchdog failure
DefaultDependencies=false

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl --full list-jobs
ExecStart=/usr/bin/systemctl start emergency.target
systemctl daemon-reload
journalctl -n10 
# Ругани на юниты в логе быть не должно
systemctl enable boot-watchdog.target
systemctl show -p Wants default.target --no-pager
# должен как минимум быть DM и boot-watchdog.target
systemctl show -p OnFailure -p JobTimeoutUSec default.target
# должно быть пусто
systemctl show -p OnFailure -p JobTimeoutUSec -p StandardOutput boot-watchdog.service 
# должен быть boot-watchdog.service, 40с, и не (null или inherit)

В случае зависона, если default.target не достижим за 40 сек, вотч вывалится и дампнет рабочие таски в stdout. В твоем варианте StandardOutput==journal, по идее выхлоп надо будет смотреть в journalctl -b. У тебя там с журналом какая то ботва, так что если ничего не будет, поменяй в system.conf

#DefaultStandardOutput=journal

на

DefaultStandardOutput=journal+console

Или что там у тебя корректнее работает/работало.

systemd 188

Странно, вроде 195 должен быть в итоге

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

И именно тут его главная ошибка.

тут есть 2 момента: 1). если в для системы отсутствие записи логов является критической ошибкой, то тот факт, что syslog (именно реализации демонов) существенно сложнее сильно повышает вероятность ошибки. Ну и любое приложение плюющееся логами не заметит отсуствие логирущей программы неважно в каком виде, если это не так, то всё плохо. 2). сислог формально образует бутылочное горлышко, т.к. время обработки лога напрямую зависит от кол-ва сервисов (правил логирования), а идёт оно через одну шину.

Оба эти фактора минимум верны, являются ли они критичными для конкретного юзкейса это вопрос конкретного юзкейса.

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

тут какое-то непонимаение. иерархическая модель логирования это printf в stderr в программе и запуск в пожиратель логов (если его нету, то перенаправление stderr в свой stderr). Для программы вызов syslog или printf в большом случае абсолютно идеентично.

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

а давайте вы почитаете man 5 init (из upstart), а я не буду оттуда ничего копипастить? там полсотни строк.

Полтыщи строк, если точнее. И на мои вопросы там ответа нет.

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

У тебя там все в waiting таски. Это в 90% случаев говно с mount, когда сорс устройства неверный. Правда я ожидал увидеть none /tmp, так что похоже это другие 10% (%

Но все же покажи

systemctl show -p WantedBy -p Wants -p Requires local-fs-pre.target
systemctl show -p After systemd-fsck-root.service
systemctl show -p After systemd-remount-fs.service
systemctl show -p RequiredBy -- -.mount

и полные

systemctl show tmp.mount
systemctl show sys-kernel-config.mount
systemctl show sys-fs-fuse-connections.mount

А так же

grep -e fuse -e tmpfs /proc/filesystems

И за одно /etc/fstab покажи. Кстати /dev/shm можно смело комментировать, он и так монтируется.

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