> #systemctl mask unit.service

systemd — единственная система инициализации/менеджер, где возможность выстрелить себе в ногу официально задокументирована и преподносится как фича.

Ну дык, задокументированный баг становиться фичей автоматически

> systemd — единственная система инициализации/менеджер, где возможность выстрелить
> себе в ногу официально задокументирована и преподносится как фича.

В любой *nix-образной системе можно выстрелить себе в ногу. На то и админ что имеет право делать что хочет. Даже стрелять себе в ноги.

> В любой *nix-образной системе можно выстрелить себе в ногу. На то и
> админ что имеет право делать что хочет. Даже стрелять себе в
> ноги.

Можно подумать в windows-системах не так. Кроме того, конкретно в случае с systemd, отличие реальности от документации разве прибавляет приложению привлекательности?

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

> Если юзер не знает, что делает, то ему лучше оставить все по
> дефолту и не трогать. Иначе он выстрелит себе в ногу, как
> с документированной, так и не с документированной возможностью.

А ты уверен что знаешь что делаешь? Очень хотелось бы тебя посмотреть на тебя в работе, когда на просьбу руководства сделать отключить 1 сервис ты идешь читать документацию. (утрирую)

>Он вообще с большими файлами работал, что придумал /tmp в память запихивать?

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

Загрузку это НЕ ускоряет, можете сами проверить. И я не против монтирования в память, тем кому это нужно. Но что за манера, если нет указания на монтирование /tmp в fstab, то сам смонтирует в память... Захочу в память монтировать - так и напишу, но в fstab, а не где этому Поттерингу вздумалось. Этак и вовсе без fstab останемся, а зачем он, системд и Поттеринг лучше знают что для меня лучше.

> Этак и вовсе без fstab останемся,

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

Это я знаю. Но пока он всё ещё "прислушивается" к тому что я в fstab написал, но такими темпами просто положит болт на fstab.

Эх... Мир больше никогда не будет прежним... Дайте йаду

> Это я знаю. Но пока он всё ещё "прислушивается" к тому что
> я в fstab написал, но такими темпами просто положит болт на
> fstab.
> Эх... Мир больше никогда не будет прежним... Дайте йаду

Это я к тому что не «эдак мы дойдём до», а именно туда мы и идём.

А вместо fstab – что? Как еще указать системе, что и куда монтировать при загрузке? Или как в венде - будем все на одном устройстве/разделе хранить и радоваться пол-часа?

> А вместо fstab – что?

Systemd.

И.О.К.О.

>А вместо fstab – что?

http://www.freedesktop.org/software/systemd/man/systemd.moun...
уже давно так.

> Это я к тому что не «эдак мы дойдём до», а именно
> туда мы и идём.

скатертью дорога.

> Эх... Мир больше никогда не будет прежним...

Дефолтный арч и несколько rpm-дистров — это ещё не весь Мир.

> Эх... Мир больше никогда не будет прежним... Дайте йаду

А может тебе просто пора уже изучить свойства используемой системы получше и осознать что если хочется мегакастома то придется проявить разборчивость и/или поработать ручками? Если подумать - даже свою систему инициализации написать по минимуму не так уж сложно. Не говоря уж о юзеже готовой.

p.s. так, чисто по человечески, какая тебе разница - девятой стартанет программа или десятой? В systemd и прочих подобных сделали логичнее: программа стартанет тогда, когда для этого наступят условия. Сетевой демон - взлетит не пятым и не восьмым, ибо это маразм. Он взлетит когда повяилась сеть. Ну мало ли, он например хотел на конкретный сетевой и-фейс сесть и вполне конкретный айпишник. Запуск его что пятым, что восьмым подобного вообще не гарантирует. А вот запуск по условию типа "стартанула сеть" - очень даже может.

фстаб это костыль, не место ему в 21.2 веке

> фстаб это костыль, не место ему в 21.2 веке

Слава бинарному реестру!

Да? и что же предлагает впердепланетный системд?
Убрали один конфиг файл, добавили другой, переложили в другое место и резко наступила "современность"? Что изменилось?

> Да? и что же предлагает впердепланетный системд?
> Убрали один конфиг файл, добавили другой, переложили в другое место и резко
> наступила "современность"? Что изменилось?

Фу, какой ты не модный. Ты может ещё гламурные журналы не читаешь и дом2 не смотришь!?

>Какой-то прыщь прибил всё гвоздями и сказал что это прогресс!

это уже в стиле m$ - всех поставить перед фактом.

Плак-плак. Кто-то этих "всех" заставляет использовать systemd? А может все иначе. Может, самом деле, ты жрешь что дают?

оставь при себе свои предположения, я не использую systemd.

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

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

> Тогда почему тебя волнует что используют другие?

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

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

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

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

> Вы просто не с того конца к нему подходите.

Нововведения должны упрощать предыдущие задачи.
Упрощения контроля за загрузкой я не вижу.
Поттеринг создал монстра раз в 50 тупее и сложнее, чем sysvinit.

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

Их же отключи от интернета, и всё, пистец - интеллект уползает под плинтус,
без форумов, гугля, википедии, стэкоферфлоу,..., они никто.

Можете проверить себя - напишите строку ядру которая зарезервирует 11 прерывание под eth0

> Мейнтейнеры дистрибутивов systemd выбрали не потому что он вам усложняет жизнь. А
> потому что он вам ее облегчит и будет экономить время.

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

а перед кем тут бисер метать? "экономить время" - уже было доказательство, что не быстрее. разве нужно доказывать всякий раз тем, кто не прочитал, или сравнивает загрузку системы на systemd & SSD против загрузки init & HDD.

> а перед кем тут бисер метать?

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

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

> даже «руки-ножницы» upstart выглядит намного логичней и удобней
> системды (и да, отлично позволяет параллельный запуск, job control, имеет систему
> событий и ты пы) — но как-то никто его внедрять не
> ломился.

что-то не клеится
upstart - RHEL6, ну и соответственно по цепочке - CentOS, Oracle Linux, Scientific, ...

>> даже «руки-ножницы» upstart выглядит намного логичней и удобней
>> системды (и да, отлично позволяет параллельный запуск, job control, имеет систему
>> событий и ты пы) — но как-то никто его внедрять не
>> ломился.
> что-то не клеится
> upstart - RHEL6, ну и соответственно по цепочке - CentOS, Oracle Linux,
> Scientific, ...

Только в RHEL7 будет systemd, ну и соответственно по цепочке...

>>> даже «руки-ножницы» upstart выглядит намного логичней и удобней
>>> системды (и да, отлично позволяет параллельный запуск, job control, имеет систему
>>> событий и ты пы) — но как-то никто его внедрять не
>>> ломился.
>> что-то не клеится
>> upstart - RHEL6, ну и соответственно по цепочке - CentOS, Oracle Linux,
>> Scientific, ...
> Только в RHEL7 будет systemd, ну и соответственно по цепочке...

обещают, конечно пока не 100%, значит есть резон, в редхате поди не идиоты и не истерики сидят

> что-то не клеится

попробуй перестать клей нюхать.

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

Ну, справедливости ради: в знаменитом FAQ-е Леннарт писал, что скорость загрузки никогда не была главной целью системд. Правда, в этом ответе он не написал, что же было главной целью :)

В целом, должен сказать, для юзера системд вполне себе ок. На Арчике работает хорошо.
Маны достаточно детально описывают все, что надо юзеру: что где написать, как чего добиться...

Но с точки зрения гика это не ок. Раньше я точно знал, что и когда запускается, какой файл за что отвечает, и если, скажем, имя конфиг файла мне нравилось, я мог спокойно изменить процедуру загрузки так, чтоб использовался другой файл. И удовольствие даже не в такой возможности, а в том, что понять как это сделать можно было, не прибегая к зазубриванию, гуглению и даже манам.
Системд все ставит на рельсы. Сторонники системд называют это стандартизацией и причисляют к бенефитам. Бенефит сомнительный, т.к. появилась необходимость что-то заучивать. Да и гики любят линукс за отсутствие рельс, свободу и легкость адаптации под свои нужды.

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

Для кого делали системд, таким образом, — загадка.

> Для кого делали системд, таким образом, — загадка.

судя по всему — для вчерашних школьников, которые периодически пробегают здесь с криками «ололо, админы-старпёры пол-жизни учили bash, а теперь это не нужно и их уволят (а возьмут крутых нас)!»

bash учили аж месяц, а потом привыкали к различиям в bash,dash,zsh,tcsh.

> bash учили аж месяц, а потом привыкали к различиям в bash,dash,zsh,tcsh.

а зачем? что, шебанг на /bin/bash — религия запрещает? ну, тогда можно и помучиться, если так охота.

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

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

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

> Много чинил и обновлял чужих порнянок на чужом железе, полных гениальными самопальными
> "улучшениями" для обхода глючащего железа? Вот с системд будет гораздо проще.

Берём компилятор... ой, слушайте, а расскажите-ка подробнее сами, прям заинтриговали.

какое доказательство было? алё-алё. речь о скорости настройки до работоспособного состояния для 99% пользователей. прицепились, блин, к скорости запуска - ничего за ней не видите и не воспринимаете. фанатики одним словом

> Ну и плюс надо иметь в виду, что он пока в фазе
> активной доработки, и делать на это скидку.

с чего бы? если его запихали в дистрибутивы — значит, системды стабилен. и никаких «скидок» ему не будет. на выходе получаем: «стабильная» программа ведёт себя как tech prebeta, постоянно что-то меняют, ломая совместимость.

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

> с чего бы? если его запихали в дистрибутивы — значит, системды стабилен.

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

>> с чего бы? если его запихали в дистрибутивы — значит, системды стабилен.
> ой, не факт. запиливать или нет решает мейнтейнер далеко не по одному
> признаку стабильности

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

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

Боюсь, что мэйнтейнеры дистрибутивов systemd выбрали потому, что он ИМ облегчает жизнь.
А вот пользователям, напротив, усложняет по закону рычага.
И никакая "филозофия systemd" отношения к этому не имеет. И вообще "философия systemd" - это оксюморон. Вы бы еще "философию Виндовс" или "философию Билли" сюда приплели...

> Мейнтейнеры дистрибутивов systemd выбрали не потому что он вам усложняет жизнь.
> А потому что он вам ее облегчит и будет экономить время.

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

Если Вы не релиз-менеджер -- не имеете права высказываться за них, то есть нас.

> Ну и плюс надо иметь в виду, что он пока в фазе
> активной доработки, и делать на это скидку.

Мальчик, скидку делают в экспериментальной эксплуатации.  В боевой скидок не положено.

И то, что идиоты из редхата стали всеми способами пропихивать это сырое поделие во все щели, при этом сами вовсе не спешат выпускать RHEL7 с ним -- кое о чём говорит.  Другие идиоты из редхата, помнится, пропихивали не менее сырой apache httpd 2.0.

>> Мейнтейнеры дистрибутивов systemd выбрали не потому что он вам усложняет жизнь.
>> А потому что он вам ее облегчит и будет экономить время.
> А давайте Вы это будете кому-то другому рассказывать, ладно?  Вчера угробил
> на это недоразумение очередных лишних часа полтора.

В целях обывательского интереса: на что ушли эти полтора часа? Init-скрипты к пакетам дописывали? )

> В целях обывательского интереса: на что ушли эти полтора часа?

На выяснение того, почему перед multi-user.target не запускается нужный сервис, как сказано.  И это уже по воспоминаниям предыдущих разбирательств на ту же тему, не с нуля.

> Init-скрипты к пакетам дописывали? )

Они там и так есть.

>> В целях обывательского интереса: на что ушли эти полтора часа?
> На выяснение того, почему перед multi-user.target не запускается нужный сервис

Или вот прямщас(tm): как должна быть оформлена зависимость в unit-файле, запускающем скрипт, который дёргает с обработанными данными бинарь, который отправляет сообщение через dbus, но не остаётся в качестве dbus-сервиса?

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

Вот итоговый дифф между "как ожидалось" и "как работает":

-After=systemd-remount-fs.service
+Requires=dbus.service
+After=systemd-remount-fs.service dbus.service

А вот избыточный работающий вариант, который в несколько итераций был сведён к вышеуказанному:

-Requires=dbus.socket
-After=systemd-remount-fs.service
+Requires=dbus.socket dbus.service
+Wants=dbus.target
+After=systemd-remount-fs.service dbus.service

Не находите немножко противоречащим принципу наименьшего удивления?  Ожидал, что хватит

Requires=dbus.service

забавно. то есть, цель requires не означает автоматически «дожидаться полного запуска сервиса»? круто. и вот эти люди будут нам рассказывать про «устаревший sysvinit со скриптовыми портянками».

лёня, по ходу, очень болен, его лечить надо, а не позволять «замену иниту» кодить.

>[оверквотинг удален]
> в идеале должно просто работать как ожидается.
> Вот итоговый дифф между "как ожидалось" и "как работает":

-After=systemd-remount-fs.service 
> +Requires=dbus.service 
> +After=systemd-remount-fs.service dbus.service

А вот избыточный работающий
> вариант, который в несколько итераций был сведён к вышеуказанному:

-Requires=dbus.socket 
> -After=systemd-remount-fs.service 
> +Requires=dbus.socket dbus.service 
> +Wants=dbus.target 
> +After=systemd-remount-fs.service dbus.service

> Не находите немножко противоречащим принципу наименьшего удивления?  Ожидал, что хватит

Requires=dbus.service

А всего-то надо было сделать:

Requires=dbus.target

Без никаких Wants=, так как Wants= тут как лошади седло:
A weaker version of Requires=. A unit listed in this option will be started if the configuring unit is. However, if the listed unit fails to start up or cannot be added to the transaction this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit.

И зачем вы ожидаете сразу и dbus.socket, и dbus.service???

Как и следовало ожидать - полтора часа траха, вместо 5-ти минутного чтения манов.

P.S.: озвучьте демон и логику запуска, если не трудно.

охрененно очевидное решение.

> охрененно очевидное решение.

Ну я уже два раза пытался написать правильное и очевидное решение, но сообщения трут. Видимо потому, что там есть нелестный отзыв о г-не Ш.  )

>> охрененно очевидное решение.
> Ну я уже два раза пытался написать правильное и очевидное решение, но
> сообщения трут. Видимо потому, что там есть нелестный отзыв о г-не
> Ш.  )
> охрененно очевидное решение.

(Третья попытка без мата)

Это если совсем в лоб. Проблема в том, что указана директива

After=systemd-remount-fs.service dbus.service

А After=. значит, что:

Before=, After=
           Configures ordering dependencies between units. If a unit foo.service contains a setting Before=bar.service and both units are being started, bar.service's start-up is delayed until foo.service is started up. Note that this setting is independent of and orthogonal to the requirement dependencies as configured by Requires=. It is a common pattern to include a unit name in both the After= and Requires= option in which case the unit listed will be started before the unit that is configured with these options. This option may be specified more than once, in which case ordering dependencies for all listed names are created.  After= is the inverse of Before=, i.e. while After= ensures that the configured unit is started after the listed unit finished starting up, Before= ensures the opposite, i.e. that the configured unit is fully started up before the listed unit is started. Note that when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied. i.
e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down. If one unit with an ordering dependency on another unit is shut down while the latter is started up, the shut down is ordered before the start-up regardless whether the ordering dependency is actually of type After= or Before=. If two units have no ordering dependencies between them, they are shut down or started up simultaneously, and no ordering takes place.

Т.е глупо просить стартовать после systemd-remount-fs.service, так как dbus.service стартует гораздо позже. И все эти попытки "угомонить разбушевавшийся и нелогичный systemd" можно решить одной простой строчкой:

After=dbus.service

P.S.: Честно говоря был лучшего мнения о г-не Шигорине. Никак не ожидал, что он не прочтет прежде документацию, вместо написания unit-файла методом брутфорса с 18-ой попытки (полтора часа / 5минут)! Да и в итоге получилось какое-то г-но. Впринципе выше правильно говорилось - майнтайнер, майнтайнеру рознь )

Ну ты то обоcpался привести решение с снятием удалённых логов средствами systemd, никто на этом внимание не акцентировал.

> Ну ты то обоcpался привести решение с снятием удалённых логов средствами systemd,
> никто на этом внимание не акцентировал.

Еще раз для особо одаренных:

journald не является реализацией syslog - соответственно и не может сам по себе быть коллектором syslog, но никто не мешает поставить тот же самый rsyslog и перенаправлять его вывод в journald.

Для больных дислексией.
Ты тут выпендривался как одной командой, в классном системд, делается всё то что лохи с старым инитом не могут сделать. А когда поступило предложение показать это на примере логирования ты сдулся. Ещё раз, вопрос звучал: покажи как одними средствами системд это сделать. Не "старыми ненужными костылями костылями", не Лёня сейчас дописывает эту мегафичу а используя новый, модный, молодёжный системд. Дислексию будешь дальше демонстрировать?

вот от этой портянки можно офигеть ещё больше: задержка запуска bar.service прописывается в конфигуре для foo.service! это офигеть как логично.

и название тоже выбрано удачно: специально, видимо, чтобы без документации можно было трактовать двояко. то ли мы запускаемся перед bar.serivice, то ли bar.service должен быть запущен до нас — фиг угадаешь. соответственно, это можно только зазубрить.

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

> вот от этой портянки можно офигеть ещё больше: задержка запуска bar.service прописывается
> в конфигуре для foo.service! это офигеть как логично.

Это вполне логично для целей типа .target, где и применяется для ожидания

suspend.target
shutdown.target
и.т.д.

Что-то подобное присутствует и в православном дебиане:

X-Start-Before: boot_facility_1 [boot_facility_2...]
X-Stop-After: boot_facility_1 [boot_facility_2...]

    provide reverse dependencies, that appear as if the listed facilities had should-start and should-stop on the package with these headers.

Но там, я так понимаю, это кошерно, в отличие от..? )

> и название тоже выбрано удачно: специально, видимо, чтобы без документации можно было
> трактовать двояко. то ли мы запускаемся перед bar.serivice, то ли bar.service
> должен быть запущен до нас — фиг угадаешь. соответственно, это можно
> только зазубрить.

Может предложите лучшее название? "Перед" - очень сложно трактовать как-то по-другому.

> если ты не в курсе, то подобный «дизайн» — очень, очень плохой:
> чем больше нелогичной зубрёжки, тем хуже. я бы понял, если бы
> над системды довлел страшный груз legacy, но нет — оно же
> «с нуля» писалось. вот только дизайнилось совершенным дилетантом, как ты в
> очередной раз продемонстрировал великолепной цитатой.

А про поддержу init-скриптов в systemd "искаропки", вы предпочитаете умалчивать? Это ли не legacy?

Зубрить, зубрежки... Познакомьтесь, наконец, с командой man и прекратите уже зубрить!

> Что-то подобное присутствует и в православном дебиане:
> Но там, я так понимаю, это кошерно, в отличие от..? )

знать не знаю, я не считаю бебиан серьёзным дистрибутивом. «OpenSSL, бугога».

> Может предложите лучшее название?

даже думать над этим не хочу. да и всё равно — поздно уже. менять.

> А про поддержу init-скриптов в systemd «искаропки», вы предпочитаете умалчивать? Это ли
> не legacy?

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

> Зубрить, зубрежки… Познакомьтесь, наконец, с командой man и прекратите уже зубрить!

дорогой, если логически вывести нельзя (а в данном случае — нельзя), то остаётся или зазубрить, или *каждый* *раз* лазить в man. оба варианта идиотичны. потому что идиотичен изначальный дизайн (точнее, отсутствие такового).

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

Очевидно, кто-то добрался и стёр по причине мата.  Непонятно, почему Вы стали дублировать #281, на которое только что и отвечал.

Моя претензия проста: документация systemd на удивление малополезна, Ваше предположение про "пять минут" крайне далеко от действительности -- на её изучение в вышеперечисленных видах были также угроблены часы.

>> Ну я уже два раза пытался написать правильное и очевидное решение, но сообщения трут.
> Очевидно, кто-то добрался и стёр по причине мата.  Непонятно, почему Вы
> стали дублировать #281, на которое только что и отвечал.

Это я уже отвечал тов. arisu

> Моя претензия проста: документация systemd на удивление малополезна, Ваше предположение
> про "пять минут" крайне далеко от действительности -- на её изучение
> в вышеперечисленных видах были также угроблены часы.

Ну вот честно - сколько надо читать, чтобы сервис запускался после dbus? Можно ведь даже без документации обойтись примеров-то полно: ARCH, Fedora, OpenSuSe...

> Ну вот честно — сколько надо читать, чтобы сервис запускался после dbus?

в нормальной системе — глянуть в /etc/rc.d/rc.M (или /etc/rc.d/rc.S, если надо пораньше). там всё красиво написано. никакие пляски с бубном не нужны: вписал строку запуска и радуешься. но хипстеры свято верят в то, что простота всегда хуже воровства, и пытаются усложнить всё, до чего могут дотянуться.

>> Моя претензия проста: документация systemd на удивление малополезна,
>> Ваше предположение про "пять минут" крайне далеко от действительности --
>> на её изучение в вышеперечисленных видах были также угроблены часы.
> Ну вот честно - сколько надо читать, чтобы сервис запускался после dbus?
> Можно ведь даже без документации обойтись примеров-то полно: ARCH, Fedora, OpenSuSe...

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

>>> Моя претензия проста: документация systemd на удивление малополезна,
>>> Ваше предположение про "пять минут" крайне далеко от действительности --
>>> на её изучение в вышеперечисленных видах были также угроблены часы.
>> Ну вот честно - сколько надо читать, чтобы сервис запускался после dbus?
>> Можно ведь даже без документации обойтись примеров-то полно: ARCH, Fedora, OpenSuSe...
> Вы по-русски читаете?  Будьте добры, прочтите мой ответ, включая упреждающий ответ
> на вот этот вопрос.

А вы по-английски?

man systemd.special
       dbus.service
           A special unit for the D-Bus bus daemon. As soon as this service is fully started up systemd will connect to it and register its service.
       dbus.socket
           A special unit for the D-Bus system bus socket. All units with Type=dbus automatically gain a dependency on this unit.

Почему бы не попробовать сразу как надо, а не городить "решение", указаний на которое *нигде* не встречается? Зачем "гробить на изучение часы" если решение лежит на поверхности?

> А всего-то надо было сделать:
>

Requires=dbus.target

Где это написано, если под рукой?  Заранее благодарен.

> И зачем вы ожидаете сразу и dbus.socket, и dbus.service???

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

> Как и следовало ожидать - полтора часа траха, вместо 5-ти минутного чтения манов.

Это не первый подход, документацию (включая fd.o и архивы рассылок) читал тоже далеко не пять минут.  Но с нуля и не зная тайных тропок.

> P.S.: озвучьте демон и логику запуска, если не трудно.

Это не демон.

http://git.altlinux.org/people/mike/packages/?p=livecd-setlo...

(про locale.* в курсе, gfxboot перековыривать на данный момент ещё более неохота с учётом логики исключений)

>> А всего-то надо было сделать:
>>

Requires=dbus.target

> Где это написано, если под рукой?  Заранее благодарен.

Этого нигде не написано, это решение "в лоб", как я и писал ниже. Правильное, с точки зрения systemd решение - и использовать директиву After=dbus.service, как и делают везде.

>> И зачем вы ожидаете сразу и dbus.socket, и dbus.service???
> Затем, что в промежуточном варианте выяснялось -- получается ли с заведомой избыточностью
> вообще добиться нужного результата.

dbus.service не cтартует без dbus.socket. Проблема в директиве

After=systemd-remount-fs.service

>> Как и следовало ожидать - полтора часа траха, вместо 5-ти минутного чтения манов.
> Это не первый подход, документацию (включая fd.o и архивы рассылок) читал тоже
> далеко не пять минут.  Но с нуля и не зная
> тайных тропок.
>> P.S.: озвучьте демон и логику запуска, если не трудно.
> Это не демон.
> http://git.altlinux.org/people/mike/packages/?p=livecd-setlo...
> (про locale.* в курсе, gfxboot перековыривать на данный момент ещё более неохота
> с учётом логики исключений)

systemd-localed.service и localectl?

странно весьма начиналось, когда логи начали шифровать, теперь еще и конфиги в бинарный формат. такое ощущение, что кому-то делать нечего, как тому коту. зачем мне дополнительные утилиты для просмотра логов и редактирования конфигураций? cat и vi нынче не в моде для таких целей, походу.
между делом мои предположения подтвердились, когда прочитал новость о примерно равной скорости загрузки при использовании systemd и init. даже где-то на опеннете новость была.

> зачем мне дополнительные утилиты для просмотра логов и редактирования конфигураций?

потому что -- есть смысл логировать много информации, а читать её мало и в комфортном виде.

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

blahblablah.1.gz
blahblablah.2.gz
blahblablah.3.gz
blahblablah.txt

ага

а потом ещё и нужно найти что-то там

И это не говоря о /var/log/wtmp и utmpdump

уникальная по новизне инфа! спасибо тебе, добрый человек. открыл, можно сказать, глаза!
>а потом ещё и нужно найти что-то там

грепом отфильтровать?

> грепом отфильтровать?

нет. grep слишком нефункциональный, в случае целей поиска по логам.

похоже что grep для чего-то другого был придуман (например -- поиск по файлам исходного кода?), а не для логов.

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

>> грепом отфильтровать?
> нет. grep слишком нефункциональный, в случае целей поиска по логам.
> похоже что grep для чего-то другого был придуман (например — поиск по
> файлам исходного кода?), а не для логов.

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

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

Для начала попроще: требуется вывести все ERROR-сообщения демона 'xyz' во время предыдущей загрузки системы.

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

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

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

#journalctl -b -1 -u xyz -p err

Есть чем ответить по делу?

Админ будет забивать голову вот этой юхнёй? А потом ему скинут на поддержку несколько серваков фряхи - алё, приехали. Надо обратно вспоминать грепы.

> Админ будет забивать голову вот этой юхнёй? А потом ему скинут на
> поддержку несколько серваков фряхи - алё, приехали. Надо обратно вспоминать грепы.

А потом несколько серваков чпукса и солярки. И снова вспоминать, как ни странно...

Ага, вот именно. Некоторые текстовки я с винды вытаскиваю на линух и использую консольные средства. Знания журналцтл мне здесь как собаке пятая нога. А вот грепы-седы разные вполне помогут и текст этот прожевать, и логи попарсить.
Но вернёмся к веселому. Там вот утилитка новая для мониторчика есть. Как её поюзать? Какие ключи есть? Есть спецключи выставления яркости как мне надо? Есть спецключи для выставления яркости в зависимости от времени суток? Есть маленькая утилитка systemd-light-sensor которая автоматом будет яркость менять? Или это будет в будущем?

> Ага, вот именно. Некоторые текстовки я с винды вытаскиваю на линух и
> использую консольные средства. Знания журналцтл мне здесь как собаке пятая нога.
> А вот грепы-седы разные вполне помогут и текст этот прожевать, и
> логи попарсить.
> Но вернёмся к веселому. Там вот утилитка новая для мониторчика есть. Как
> её поюзать? Какие ключи есть? Есть спецключи выставления яркости как мне
> надо? Есть спецключи для выставления яркости в зависимости от времени суток?
> Есть маленькая утилитка systemd-light-sensor которая автоматом будет яркость менять?
> Или это будет в будущем?

Утилитка сохраняет значение яркости между перезагрузками, по типу alsa-store для значений громкости. Какие ключи, какая автонастройка? Что вы курите, молодой человек?

> Утилитка сохраняет значение яркости между перезагрузками, по типу alsa-store для значений громкости.

А в гойлову не приходит что за компом может быть несколько человек и у каждого своё мнение об яркости? И почему утилитка запоминающая яркость не может выставить то значение что мне надо? Это не говоря о том что монитор отлично запоминает яркость которую ему выставили. Даже грузиться никуда не надо.

> Какие ключи, какая автонастройка? Что вы курите, молодой человек?

Курят здесь только поклонники Леонида. Посмотрим как через полгода эту фичу прикрутят к утилитке и ты будешь тут пысать кипятком рассказывая как жить не мог без этого.

>> Утилитка сохраняет значение яркости между перезагрузками, по типу alsa-store для значений громкости.
> А в гойлову не приходит что за компом может быть несколько человек
> и у каждого своё мнение об яркости? И почему утилитка запоминающая
> яркость не может выставить то значение что мне надо?

Ответ КЭПа: потому что она для этого не предназначена.

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

Видно у вас никогда не было ноутбука.

>> Какие ключи, какая автонастройка? Что вы курите, молодой человек?
> Курят здесь только поклонники Леонида. Посмотрим как через полгода эту фичу прикрутят
> к утилитке и ты будешь тут пысать кипятком рассказывая как жить
> не мог без этого.

Только я и слышу все "аргументы" только в сослагательном наклонении. Опять же - есть что сказать по существу?

> Ответ КЭПа: потому что она для этого не предназначена.

Подождём, я верю в гений рахитектора systemd.

> Видно у вас никогда не было ноутбука.

Как-то не было таких проблем с ноутами. Хорошо что есть Леннарт, кто бы мне сказал что до этого у меня проблемы были.

> Только я и слышу все "аргументы" только в сослагательном наклонении. Опять же - есть что сказать по существу?

Когда про втягивание udev внутрь systemd, впиливание зависимости в гном от systemd, жёсткое прибитие гвоздями бинарного журнала, невозможности выпиливания обратно хомки писали то же самое: есть что по существу,сослагательное наклонение...

слышь, я б тебе ответил. только в случае готовой команды срач будет продолжаться в стиле: а, у тебя тут больше "хх" символов получилось в строке и ничего не понятно. ой! ай! так не считается! тут у тебя пайпы какие-то, sed какой-то непонятный... уже уйма таких примеров было.
для последнего лога лучше использовать last reboot, вторая строка и дата, и время от старта до выкл.

> слышь, я б тебе ответил. только в случае готовой команды срач будет
> продолжаться в стиле: а, у тебя тут больше "хх" символов получилось
> в строке и ничего не понятно. ой! ай! так не считается!
> тут у тебя пайпы какие-то, sed какой-то непонятный... уже уйма таких
> примеров было.
> для последнего лога лучше использовать last reboot, вторая строка и дата, и
> время от старта до выкл.

В общем сдулись ребятушки )

> В общем сдулись ребятушки )

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

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

journald не является реализацией syslog - соответственно и не может сам по себе быть коллектором syslog, но никто не мешает поставить тот же самый rsyslog и перенаправлять его вывод в journald.

Теперь вопрос. Как средствами одного только системд и его подручных сливать логи с железок которых туева хуча? Старые костыли в виде сислог-демонов не предлагать.

А теперь я возвращаю фразу:
<В общем сдулись ребятушки )>

> но никто не мешает поставить тот же самый rsyslog и перенаправлять его вывод в journald.

Зачем?  К rsyslog прилагается хорошо работающий LogAnalyzer.

омойбог. и на чём споткнётся греп?

> омойбог. и на чём споткнётся греп?

http://www.opennet.me/openforum/vsluhforumID3/91726.html#176

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

Вот еще пример: вывести список ошибок отправки сообщений пользователя vpupkin за вчерашний рабочий день.

А они все такие, болезные.Они считают что в продакшене так и надо делать. Фигли, говорить если в этом ентерпайзе журналирования вот так:

[subject] journalctl -x considered harmful
...
For bug *reports* adding -x certainly doesn't make sense. Do we have
documented that somewhere?
Lennart

Автор этого текста легко угадывается.

> А они все такие, болезные.Они считают что в продакшене так и надо
> делать. Фигли, говорить если в этом ентерпайзе журналирования вот так:
> [subject] journalctl -x considered harmful
> ...
> For bug *reports* adding -x certainly doesn't make sense. Do we have
> documented that somewhere?
> Lennart
> Автор этого текста легко угадывается.

Вылезли бы уже из криокамеры, да поняли бы что делает journalctl -x

-x, --catalog
           Augment log lines with explanation texts from the message catalog. This will add explanatory help texts to log messages in the output where this is available. These short help texts will explain the context of an error or log event, possible solutions, as well as pointers to support forums, developer documentation, and any other relevant manuals. Note that help texts are not available for all messages, but only for selected ones. For more information on the message catalog, please refer to the Message Catalog Developer
           Documentation[4].
           Note: when attaching journalctl output to bug reports, please do not use -x.