Комментарии 30
Я тоже с радостью бы почитал про journalctl
.
Можно ли получить переменные окружения gui-сессии любого юзера из под рута? Всякие там xdg_* и т.д.
И еще, для чего нужна machinectl?
Подробней https://www.freedesktop.org/software/systemd/man/machinectl.html
И еще, для чего нужна machinectl?Хотите вы, например, посмотреть, что там нового и интересного в Fedora 25, качаете cloud-образ, делаете
machinectl import-tar fedora25.tar.gz
machinectl start fedora25
machinectl login fedora25
И у вас запущен контейнер с Fedora 25, с изоляцией, с собственной сетью, причем systemd-networkd сам выберет неиспользуемый диапазон частных IP-адресов, выдаст IP этому контейнеру через DHCP, настроит ему NAT, все сделает.Настроили вы Fedora, подняли там, например, прокси, и хотите посмотреть логи. Нет ничего проще! Прямо из хостовой машины их можно увидеть следующим образом:
journalctl -M fedora25 -e
Или, например, перезапустить какой-либо сервис:
systemctl -M fedora25 restart squid
Заместо известного unix-way — организуем одну огромную оболочку с не особенно прозрачными функциями и «кормящимися» от неё специальными утилитами.
Лучше уж сразу на венду с её гуями и красивыми рюшечками…
Заместо известного unix-wayС этого момента — поподробнее.
организуем одну огромную оболочку с не особенно прозрачными функциями и «кормящимися» от неё специальными утилитами.Никакой «огромной оболочки» я не вижу. Вижу кучу живущих в одном репозитории маленьких утилит. Вижу то, что было во всех версиях Unix с момента его создания.
Если вы видите что-то другое — просьба рассказать где конкретно вы это увидели и когда, в какой конкретно версии Unix оно появилось.
P.S. На всякий случай: GNU/Linux — не является Unix и, соответственно, к Unix-way прямого отношения иметь не может.
Последняя, вообще говоря, должна работать в режиме «отработала — теперь заткнись и отвали».
При этом продемонстрирована тенденция разрастания монстра — он уже не только инит заменяет с башем, но и груб.
Всё нормально, ага-ага.
Он, скорее всего, не заменяет grub, а даёт более легковесную альтернативу. Как, например, systemd-timesyncd не заменяет ntpd (а является легковесным sntp-клиентом, но не реализует серверную часть). Или systemd-networkd не заменяет networkmanager, wpa_supplicant и кучу другого софта, а даёт маленький сервис конфигурации сети для тех случаев, когда достаточно просто статической или dhcp-конфигурации.
Последняя, вообще говоря, должна работать в режиме «отработала — теперь заткнись и отвали».Вас сюда, случаем не из 60х занесло? Это в те времена чтобы конфигурацию железа изменить нужно было всё выключать. Уже в 70-е это перестало быть чем-то необычным, а сейчас — система должна как-то понимать, когда её переносят из одного города в другой, когда к ней подключают разные принтеры и флешки — и всё это, вы не поверите, без всякой перезагрузки. Даже на серверах у вас вполне могут возникать новые процессоры и новые устройства (да, конечно, виртуальные — но делает ли это ситуацию проще?).
Так что подход «отработала — теперь заткнись и отвали» не работает. Уже давно не работает. systemd — это попытка выкинуть ту гору костылей, которые были вокруг попытки заставить всё это заработать и сделать всё «по-нормальному».
Заметим что все остальные современные UNIX'ы (всякие Solaris'ы, AIX'ы и MacOS'ы) это всё проделали гораздо раньше. GNU/Linux оставался «последним из могикан».
1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.
А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.
systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
Обычно это хорошо чувствуют те, кто мейнтейнил до этого пачку init-скриптов под несколько версий более-менее разных дистрибутивов. Те же зависимости unit'ов просто прекрасны после событий upstart.
Собственно вы подтверждаете мои слова, что хейтят systemd школьники не работавшие с реальными серверами и не видившие ада старых инит-систем, а мы, с высоты своего опыта, наслаждаемся хорошим инструментом.
При этом системд активно раздувается, забирая под себя функциональность не только инита, но и других, сопряжённых вещей — от udev, башинит — уже и до груба.
Это означает непрозрачность и сложность его функционирования — особливо на фоне того, что сопровождается он кучей узкоспециализированных, неуниверсальных утилит со специфическим синтаксисом.
А вообще — главная проблема systemd в том, что его пропихивают везде безальтернативно.
Про «забирая функциональность». А вас никто не заставляет ставить те или иные части и их использовать. Вы можете использовать что-то другое. Systemd он модульный. Но вы, как любой хейтер, об этом не знаете, вы ненавидите то, что не видели и в чем не понимаете. Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.
Про непрозрачность и сложность вы пишите опять же потому, что вы не пользовались, а просто цитируете чужие слова, тут даже отвечать не буду.
Кто вам сказал про безальтернативность? В Debian/Ubuntu вы можете легким движением руки использовать upstart, sysV, openrc или systemd. А! Вам снова рассказали на сайте хейтеров, а вы сами не знаете о чем пишите. Тогда понятно.
Все ваши «аргументы» представляют из себя набор штампов с сайтов школьников-хейтеров и не соответствуют действительности.
Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.
Меня это поверье (про то, что udev невозможно было собрать без systemd) давно забавляет. Учитывая, что я своими глазами видел, что пакет udev для ubuntu (тогда с upstart'ом) собирался из дерева исходников systemd/udev без каких-либо проблем.
У меня например большие надежды на networkd потому что каждый раз мучительно вспоминать чем различается настройка сети на centos 5, 6, 7, дебиан и прочих разношерстных дистрибутивах. А если они еще менеджер пакетов реализуют то им вообще памятник надо будет поставить.
haters gonna hate, тут ничего не поделаешь.
Я недавно посмотрел на networkd на raspberry pi, оказалась очень приятная и более-менее удобная штука.
Интерфейсы само поднимает, конфигурирует по DHCP тоже без сторонней помощи. Имя интерфейса можно задать маской и иметь один юнит на всё, если кроме DHCP ничего не надо для Ethernet.
Пять инструментов systemd, которые стоит начать использовать прямо сейчас