Обсуждение: Systemd

nobus
потратил час и перешел наконец на “чистый” systemd. Никаких затруднений не испытал, полдня полет нормальный
Аналогично. Правда не торопился и посидел пару дней на init=/bin/systemd прежде чем удалить initsripts. Не завелся автоматически только upsd (network-ups-tools), хотя “покомпонентно” запускается и работает (думаю разберусь и поправлю). В остальном всё нормально - система загружается быстрее, выключается вообще мгновенно.

ИМХО, чтобы ни говорили, но по-моему systemd неплохой проект. Просто надо время, чтобы вникнуть. А поттерингоненавистики :) просто ленятся…
Просто надо время, чтобы вникнуть.
А пока все вникают, его, глядишь, и допилят совсем :)
согласен, покурите маны неспеша с полуполным переводом… я вот даже чуть после монтирования шар по запросу через системд, чуть не выбросил фстаб, но к сожалению заменить корневой юнит на свой пока не удалось, вроде все делаю так, как делает генератор встроенный в системд, но пока не катит(не хочет он). Добавлю не большое рилическое отступление.
Как бы тоже отсчетик.(Вообще учитывая возможные вопросы в будущем, вроде “как оно ребята”, может к таким мнениям прикрепить топик, для более быстрого поиска и рефера вопрошающего)
—-
Вот уже 2 недели на чистом и 3 на миксовом системд, первую неделю просто повторял за вики, последнюю неделю одолел пока не все, но точно те что знал, маны. (Хотя для базового управления вполне хватит нашей википедии, храни ее господь)
Все, что там написано, все вроде работает. Однако все же стоит отметить, что плохо подвергаются модификации системные (static) юниты(изменяются они на ура, но почемуто система не всегда реагирует на изменения), что кидает внятную тень на свободу, которой проникаешься, конфигурируя те свои первые личные два юнита))) . Я не знаю почему так происходит. От того что я не совсем глубоко понял внутреннее устройство, а также обоюдные зависимости этих состовляющих и это не баг, а криворукость, или это баг, или это дефакто не пользовательского ума дела эти вещи… не ясно мне. Однако мне пришлось трогать их, только изза дефекта со шрифтом в процессе активизации фреймбуфера, в итоге ,благодаря смекалке Natrio, мы решили проблему полностью в обход раннего процесса загрузки системд, соответственно я вернул все “измененные” системные юниты к стартовому состоянию и теперь думаю только опираться на них, но не пинать их, ногу уже одбил -).
Также нет литературы стандартной логики системы (ну или покорный слуга прошел мимо) на раннем старте, отчего приходится выцарапывать инфу почутку, ориентируясь на известные юниты(special), к счастью их не так много. Но однако результаты возможны только после длительных ребутов и экпериментов с секцией Unit. Однако, отведу страх переходящих, как правило ранний этап загрузки не изменяется и нормально работает из коробки.
Возникли также затруднения с сетевыми шарами, которые монтируются не автоматом из фстаб, а в цикле “жизнипроцесса” пользователя, вероятно это связано с тем, что сеть так шустро накрываемая системд, приводила к сбойной размантировке шары, отчего таймаут драйвера фс приходилось ждать при выключении/перезагрузке аппарата. Однако, если монтировать эти шары юнитами, неважно как (не забудьте на всякий пожарный указывать Conflicts=umount.target) то проблема рассасывается, к сожалению я еще не могу сказать что этот эффект может задеть все уфс (ssh ftp nfs и пр.) , но могу говорить о smb (cifs). Можно (наверно) и задержать network.target и др. юниты отвечающие за ваши сетевые адаптеры, но так как нога у меня уже болит, а юнит системный, я решил не ввязываться, подумав, что мне не только удобней , но и выгодней примонтировать шары юнитами, тем самым дав явно системд понять о их наличие. Временые монтирования я рекомендую не забывать размонтировывать руками, до заброса машины в poweroff/reboot, если это приводит к задержкам.
Несмотря на то, что я перечисляю конфузы встретившиеся мне, заметьте, что в них нет ничего из главных функций , которые могли бы вызвать серьезные аварии. Значит я намекаю, на то, что они работают с первого старта как надо.
Генератор fstab работает как часы… китайские.. шучу) . Как часы, сбоев не заметил. Порадовал тот факт, что если пользователь один в системе, то он может без sudo скомандовать systemctl reboot/poweroff и отправить систему в космос. Так как у меня не DE, а скромные вм, мне сий факт позволил избавится от некоторых костылей, например убрать разрешение на пуск reboot/poweroff без пароля. (Да , я так выключался из менюшек, мне это показалось логичным более простым в настройке). Что еще точно можно отметить…Наверно мгновенную смерть пк. Она реально бытсрее. По поводу старта, давайте я осторожно скажу , что она не стала медленней ;) Ну я думаю, тот кто может сказать, что она уступает функционалом какойнито др. системе инициализации, может проходит мимо . ;)
А теперь маленький итог:
Поставив системд в качестве сис. инициализации, я получил готовую рабочую систему после старта, которую быстро довел до состояния сисВинит варианта, оперирую только вводной статьей, вполне объемной, арчвики. А теперь и внес значительные улучшения. Т.е. уже пробовать можно, не факт , что кушать. Имхо. Спасибо за внимание
$ uname -a;date
Linux jinnlamp 3.4.9-1-ARCH #1 SMP PREEMPT Wed Aug 15 18:11:01 UTC 2012 i686 GNU/Linux
Пт. авг. 24 01:30:09 MSK 2012
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
lampslave
А пока все вникают, его, глядишь, и допилят совсем :)
Попросили помочь установить systemd. За одно и себе поставил ;-)
Оказывается его уже допилили и весьма неплохо. Установить 2 пакета, включить 3 сервиса и все готово.
И кстати. Пока, на 2х железках, с русским все нормально без допила.
Lupus pilum mutat, non mentem.
Насчёт ранней загрузки – тут есть “небольшая” хитрость со стороны systemd.

Если посмотреть
systemctl show юнит.service
у юнита обнаруживаются дополнительные зависимости, добавленные systemd по-умолчанию. Эти зависимости обычно “очевидны” для обычных юнитов, которые грузятся в мульти-юзере, но если юнит должен грузиться на ранних стадиях, дефолтные зависимости необходимо убрать, потому что они в это время ещё не загружены, и прописать всё что нужно руками. Для этого есть опция DefaultDependencies=false в секции
Кто-нибудь замечал в логе такое?
systemd-tmpfiles: stat(/run/user/1000/gvfs) failed: Permission denied
На забугорном форуме есть подобная тема без решения.
Leonardo19
Кто-нибудь замечал в логе такое?

systemd-tmpfiles: stat(/run/user/1000/gvfs) failed: Permission denied


На забугорном форуме есть подобная тема без решения.

Оно?
time lords
Оно?
Вероятно оно. Только не улавливаю, что конкретно надо сделать.
Права на папку dr-x——.
Ага. Файла /usr/lib/tmpfiles.d/gvfs.conf нет. Надо создать /etc/tmpfiles.d/gvfs.conf и прописать в нем. Что прописать?
Я не уверен, что это правильно (не знаю что такое gvfs и зачем оно :) ). Еще было бы интересно узнать что за юнит его запускает

D /run/user/1000/gvfs 0755 пользователь пользователь

А вообще можно попробовать сменить владельца каталога /run/user/1000/ рекурсивно. В терминале под рутом:
chown -R пользователь:пользователь /run/user/1000/ 
 
Зарегистрироваться или войдите чтобы оставить сообщение.