Comments 30
А что, управление загрузкой настолько важный инструмент, который необходим каждый день? :)
systemd (как следует из названия) предназначен для того, чтобы управлять не загрузкой, а системой. И да, это может быть необходимо каждый день. Вернее каждый день, когда возникают проблемы. Если сервер и так работает «как часы», то лезть в него, понятно, не нужно, но если что-то не работает, то…
Как и дампы ядра, собственно.
Уж лучше бы рассказали людям про journalctl и его полезные фичи, типа journalctl --since yesterday.
Я тоже с радостью бы почитал про journalctl.
У journalctl есть один минус: к нему надо привыкать. После долгих лет грепанья по логам нужно привыкнуть, что теперь ты можешь сказать «Хочу логи начиная со вчерашнего числа» или «Хочу логи с 15 часов 1 ноября до 16 часов 3 ноября» и их увидеть ничего не грепая, просто одной командой. А так вышел прекрасный инструмент, только за него уже можно Леннарту ставить памятник от благодарных админов.
Расскажем, ждите новых публикаций!
Офтоп, но может подскажете))
Можно ли получить переменные окружения gui-сессии любого юзера из под рута? Всякие там xdg_* и т.д.
И еще, для чего нужна machinectl?
Можно ли получить переменные окружения gui-сессии любого юзера из под рута? Всякие там xdg_* и т.д.
И еще, для чего нужна machinectl?
machinectl для работы с контейнерами нужна, входит в пакет systemd-container, чем изрядно об этом намекает.
Подробней https://www.freedesktop.org/software/systemd/man/machinectl.html
Подробней 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, подняли там, например, прокси, и хотите посмотреть логи. Нет ничего проще! Прямо из хостовой машины их можно увидеть следующим образом:
journalctl -M fedora25 -eИли, например, перезапустить какой-либо сервис:
systemctl -M fedora25 restart squid
Непонятно, зачем это всё надо.
Заместо известного unix-way — организуем одну огромную оболочку с не особенно прозрачными функциями и «кормящимися» от неё специальными утилитами.
Лучше уж сразу на венду с её гуями и красивыми рюшечками…
Заместо известного 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 оставался «последним из могикан».
Непонятно что вы имеете в виду под unix-way. Обычно systemd-хейтеры находятся в возрасте 14-18 лет и настоящих Unix™ в глаза не видели.
1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.
А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.
1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.
А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.
systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
Обычно это хорошо чувствуют те, кто мейнтейнил до этого пачку init-скриптов под несколько версий более-менее разных дистрибутивов. Те же зависимости unit'ов просто прекрасны после событий upstart.
После апстарта все что угодно покажется раем, будем честны. Нормальные зависимости были в openrc, но он нигде, кроме Gentoo, не прижился. А upstart был каким-то выкидышем, извините, вроде и хотели сделать лучше, чем было, а вышло черти что и сбоку бантик.
Собственно вы подтверждаете мои слова, что хейтят systemd школьники не работавшие с реальными серверами и не видившие ада старых инит-систем, а мы, с высоты своего опыта, наслаждаемся хорошим инструментом.
Собственно вы подтверждаете мои слова, что хейтят systemd школьники не работавшие с реальными серверами и не видившие ада старых инит-систем, а мы, с высоты своего опыта, наслаждаемся хорошим инструментом.
Ваше суждение содержит исключительно оценочные, непроверяемые характеристики, т.е. выглядит сектанским по сути.
При этом системд активно раздувается, забирая под себя функциональность не только инита, но и других, сопряжённых вещей — от udev, башинит — уже и до груба.
Это означает непрозрачность и сложность его функционирования — особливо на фоне того, что сопровождается он кучей узкоспециализированных, неуниверсальных утилит со специфическим синтаксисом.
А вообще — главная проблема systemd в том, что его пропихивают везде безальтернативно.
При этом системд активно раздувается, забирая под себя функциональность не только инита, но и других, сопряжённых вещей — от udev, башинит — уже и до груба.
Это означает непрозрачность и сложность его функционирования — особливо на фоне того, что сопровождается он кучей узкоспециализированных, неуниверсальных утилит со специфическим синтаксисом.
А вообще — главная проблема systemd в том, что его пропихивают везде безальтернативно.
Мое мнение — мнение профессионала. А про «сектантство» это вам, как раз, к системд-хейтерам. Сейчас у меня сервера с upstart и systemd, мне нет разницы с чем работать, но с systemd удобней.
Про «забирая функциональность». А вас никто не заставляет ставить те или иные части и их использовать. Вы можете использовать что-то другое. Systemd он модульный. Но вы, как любой хейтер, об этом не знаете, вы ненавидите то, что не видели и в чем не понимаете. Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.
Про непрозрачность и сложность вы пишите опять же потому, что вы не пользовались, а просто цитируете чужие слова, тут даже отвечать не буду.
Кто вам сказал про безальтернативность? В Debian/Ubuntu вы можете легким движением руки использовать upstart, sysV, openrc или 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 без каких-либо проблем.
Если получится то лучше напишите статью о часто используемых частях systemd. Про journalctl уже попросили. А вот networkd, systemctl, timesyncd, systemd и др можно подробнее рассказать, может после этого хейтеров поменьше будет, а знания у людей побольше.
У меня например большие надежды на networkd потому что каждый раз мучительно вспоминать чем различается настройка сети на centos 5, 6, 7, дебиан и прочих разношерстных дистрибутивах. А если они еще менеджер пакетов реализуют то им вообще памятник надо будет поставить.
У меня например большие надежды на networkd потому что каждый раз мучительно вспоминать чем различается настройка сети на centos 5, 6, 7, дебиан и прочих разношерстных дистрибутивах. А если они еще менеджер пакетов реализуют то им вообще памятник надо будет поставить.
haters gonna hate, тут ничего не поделаешь.
Я недавно посмотрел на networkd на raspberry pi, оказалась очень приятная и более-менее удобная штука.
То есть рекомендуете на networkd посмотреть? Просто я как-то живу без networkd(хейтер выше от факта, что systemd работает со старыми настройками сети может пойти и поплакать в углу, такое опровержение его бреда про замену всего), но есть где провести эксперименты и глянуть. А не опишите в кратце в чем удобство? Чем оно лучше привычного мне /etc/network/interfaces? На что стоит обратить внимание?
После слов «привычного мне /etc/network/interfaces» сразу понятно что у вас дебианоподобный дистрибутив и вы думаете что так же везде. А некоторые задают вопросы в стиле «I work now with Centos 5.4 and I would like configure my Ethernet, but I can't find the /etc/network/interfaces. Have you andy idea?» ( https://www.centos.org/forums/viewtopic.php?t=26110 ). То что вы живете прекрасно без развития это понятно. Еще каких то сто лет назад люди прекрасно вообще без компьютеров жили и не надо вот это всего было. Вы так же можете сюда добавить сентенции «не трогай пока работает» и «они бы еще ОС написали». Так же вы кажется перепутали systemd и networkd, первый как раз и стартует старые системы управления сетью, от того вам и кажется что он работает со старыми. Второй же напротив имеет свой собственный формат конфигов и с другими не работает.
Перешел на systemd-networkd в jessie, когда хотел воспользоваться целью «systemd-networkd-wait-online» в самописном юните, а оно не сработало как надо.
Интерфейсы само поднимает, конфигурирует по DHCP тоже без сторонней помощи. Имя интерфейса можно задать маской и иметь один юнит на всё, если кроме DHCP ничего не надо для Ethernet.
Интерфейсы само поднимает, конфигурирует по DHCP тоже без сторонней помощи. Имя интерфейса можно задать маской и иметь один юнит на всё, если кроме DHCP ничего не надо для Ethernet.
А если они просто новую ось сразу напишут вокруг этого, то из золота отлить?) Надо уметь вовремя останавливаться.
Вот это всё с какой версии systemd работает? Упоминания в статье не нашел.
Sign up to leave a comment.
Пять инструментов systemd, которые стоит начать использовать прямо сейчас