Переход Ubuntu на Systemd

[Hephaestus]

Ага. А если Xorg завершается с ошибкой, то и KDM завершается с ошибкой. Что ему остаётся, если он и свою мордочку отрисовать не в состоянии?

А дальше доблестный sytemd упорно перезапускает "упавший демон" kdm... вечно!

[Vascom]

А в Федоре всё нормально.
Кто-то в других дистрибутивах косячит. Может это диверсия такая просто?

[Rootlexx]

KDM вообще-то сам запускает Xorg

Ага. А если Xorg завершается с ошибкой, то и KDM завершается с ошибкой. Что ему остаётся, если он и свою мордочку отрисовать не в состоянии?

root

root@debian:~# echo rubbish > /etc/X11/xorg.conf root@debian:~# invoke-rc.d kdm start [ ok ] Starting K Display Manager: kdm root@debian:~# ps -C Xorg PID TTY TIME CMD root@debian:~# invoke-rc.d kdm status [ ok ] kdm is running root@debian:~# ps -C kdm PID TTY TIME CMD 21405 ? 00:00:00 kdm root@debian:~#

И после удаления xorg.conf можно без проблем стартовать графический сервер командой kdmctl reserve и войти в систему.

[alv]

А в Федоре всё нормально.
Кто-то в других дистрибутивах косячит. Может это диверсия такая просто?

Наконец-то докопались до сути.
Это мировой жидомасонский заговор поттероненавистников.
Они внедрились в техсоветы и core teams всех передовых дистрибутивов.
Где активно внедряют systemd для того, чтобы косячить его напропалую.
Имея своей гнусной целью дискредитацию идей мировой революции systemd'изации и лично товарища Поттеринга в скобках Леннина.
Вроде как тайные кулаки, враги советской власти, в годы Всеобщей коллективизации, распространяли слухи, что все колхозники будут спать под одним одеялом.
Но не оскудеет сообщество бдительными пионерами! Выведут врагов на чистую воду!

[Bizdelnick]

Rootlexx
Занятно. Выходит, в каких-то версиях было не так.

[den_beckett]

Нуво, блоб. Да и как тут с дровами может быть связано? Это уже внутри X'ов.

Да очень просто - ядро обновилось, а дрова и модуль ядреный - нет. Dkms должен его пересобрать, при следующем старте системы, автоматически. Но это в теории, а на практике dkms в OpenSUSE работал по большим праздникам. Зулусского календаря, ога.

Вроде в пакете bumblee есть такое. Хотя я даже не знаю, что это, и с чем его едят (кроме того, что в википедии 2 строчки прочёл).

Не, bumblebee - это из совсем другой оперы.

а как ты прочитаешь QR код для открытия бинарного лога из sh?

/usr/bin/journal [options] <path-to-log>, не? (чисто теоретически, на практике не пробовал)

Очень по-поцовски. Стильно, модно, молодежно... И ручками сервисы запускать. Из-под поцтеровысера. Ога, ога...

Я имел в виду - для ремонтных работ. Чтобы сисьтемды не мешался под ногами.

А дальше доблестный sytemd упорно перезапускает "упавший демон" kdm... вечно!

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

[NickLion]

Нуво, блоб. Да и как тут с дровами может быть связано? Это уже внутри X'ов.

Да очень просто - ядро обновилось, а дрова и модуль ядреный - нет. Dkms должен его пересобрать, при следующем старте системы, автоматически. Но это в теории, а на практике dkms в OpenSUSE работал по большим праздникам. Зулусского календаря, ога.

Речь о systemd была. dkms не обсуждал, он вообще в suse был включён? Вроде в основном репозитории нет такого пакета вообще.

Вроде в пакете bumblee есть такое. Хотя я даже не знаю, что это, и с чем его едят (кроме того, что в википедии 2 строчки прочёл).

Не, bumblebee - это из совсем другой оперы.

Оговорился, не пакет, а репозиторий. В нём пакет dkms есть.

[drBatty]

а где там вообще этот QR?

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

А так вроде были консольные утилитки для работы с QR и подобными.

там в том и фича, что ты лог НЕ откроешь, пока QR нее сфоткаешь и в другой комп(систему) не вобьёшь. Для безопасности, да. Что-бы всякие уроды и падонки init=/bin/sh не делали, а потом логи в своих тёмных целях не читали.

Ага. А если Xorg завершается с ошибкой, то и KDM завершается с ошибкой. Что ему остаётся, если он и свою мордочку отрисовать не в состоянии?

перезапустить естественно!

А в Федоре всё нормально.

а вы ещё Windows95 запустите, там тоже всё нормально, я гарантирую это! Ничего не падает и не глючит!!!111один-один

[drBatty]

root@debian:~# echo rubbish > /etc/X11/xorg.conf
root@debian:~# invoke-rc.d kdm start
[ ok ] Starting K Display Manager: kdm
root@debian:~# ps -C Xorg
PID TTY TIME CMD
root@debian:~# invoke-rc.d kdm status
[ ok ] kdm is running
root@debian:~# ps -C kdm
PID TTY TIME CMD
21405 ? 00:00:00 kdm
root@debian:~#

у меня такая ерунда тоже работает
в Slackware, без KDM и без systemd. Т.ч. не показатель.

PS:

Shell

root@amilo:~# ls /etc/X11/xorg.conf /bin/ls: невозможно получить доступ к /etc/X11/xorg.conf: Нет такого файла или каталога root@amilo:~# ps -C Xorg PID TTY TIME CMD root@amilo:~# ps -C X PID TTY TIME CMD 17724 tty7 00:00:11 X

/usr/bin/journal [options] <path-to-log>, не? (чисто теоретически, на практике не пробовал)

неа. И это фича, а не баг.

Чтобы сисьтемды не мешался под ногами.

мечтайте, я не против.

[Rootlexx]

root@debian:~# echo rubbish > /etc/X11/xorg.conf
root@debian:~# invoke-rc.d kdm start
[ ok ] Starting K Display Manager: kdm
root@debian:~# ps -C Xorg
PID TTY TIME CMD
root@debian:~# invoke-rc.d kdm status
[ ok ] kdm is running
root@debian:~# ps -C kdm
PID TTY TIME CMD
21405 ? 00:00:00 kdm
root@debian:~#

у меня такая ерунда тоже работает
в Slackware, без KDM и без systemd. Т.ч. не показатель.

Что у вас работает без KDM и systemd? Я продемонстрировал, что KDM не завершается, даже если X-сервер не запустился. А вы о чём?

PS:

Shell

root@amilo:~# ls /etc/X11/xorg.conf /bin/ls: невозможно получить доступ к /etc/X11/xorg.conf: Нет такого файла или каталога root@amilo:~# ps -C Xorg PID TTY TIME CMD root@amilo:~# ps -C X PID TTY TIME CMD 17724 tty7 00:00:11 X

В Debian процесс - Xorg:

user

user@debian:~$ ps -C X PID TTY TIME CMD user@debian:~$ ps -C Xorg PID TTY TIME CMD 3752 tty7 00:00:02 Xorg user@debian:~$ pgrep ^X 3752 user@debian:~$

[drBatty]

Что у вас работает без KDM и systemd? Я продемонстрировал, что KDM не завершается, даже если X-сервер не запустился. А вы о чём?

я знаю, что не завершается. Я о том, что почему вам можно к словам цепляться, а мне нет?

Факт в том, что KDM без Xorg не работает. А то, что он "в процессах висит" ничего не доказывает. Там много чего висит.

[Rootlexx]

Факт в том, что KDM без Xorg не работает. А то, что он "в процессах висит" ничего не доказывает. Там много чего висит.

Поэтому я и написал:

И после удаления xorg.conf можно без проблем стартовать графический сервер командой kdmctl reserve и войти в систему.

Так что несмотря на нестартующий Xorg KDM вполне работает и реагирует на команды.
А "то, что он в процессах висит" доказывает, что его процесс не завершается, а значит, не перезапускается без конца, как тут пытались утверждать.

[Hephaestus]

Так что несмотря на нестартующий Xorg KDM вполне работает и реагирует на команды.
А "то, что он в процессах висит" доказывает, что его процесс не завершается, а значит, не перезапускается без конца, как тут пытались утверждать.

Здорово. Автоматика оказалась умнее, чем я предполагал. Это с одной стороны.
А с другой?
У нас есть DM висящий в списке процессов даже при упавших иксах.
Я, припоминаю, действительно у меня так и было: иксы падали, gdm оставался. И для перезапуска иксов нужно было остановить и заново запустить gdm.

О! Превосходный пример.
Предположим, человек хочет настроить у себя средствами systemd автоматический перезапуск иксов, на случай их падения.
Как объяснить systemd, что в случае падения иксов нужно рестартовать DM?
То есть при падении одного сервиса нужно перезапускать другой сервис, не упавший, а как раз тот, который висит в процессах. Как это настроить? В статье Леннарта я таких деталей не увидел.

[drBatty]

Rootlexx
я же говорю: kdm запускает иксы от рута, а потом перезапускает от юзера. Если (пере)запустить не удалось, kdm находится в состоянии "не жив и не мёртв". Вроде как в процессах есть, но его не видно, и "реагирует на команды" должно быть в кавычках, т.к. для ендюзера это чёрный экран смерти.

В этой ситуации нужно лог читать, дабы узнать ПОЧЕМУ не запустились иксы. Ка и во всех остальных аварийных ситуациях. Для меня это очевидно, а вы продолжайте доказывать, что "kdmm висит в процессах, а значит Леннарт гений!".

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

Ну либо вы возвращайтесь к теме, и объясняйте мне, неразумному, чем в данной ситуации может помочь systemd. А то я этого по скудоумию не понимаю.


Спасибо.

[drBatty]

вести с полей: http://linuxforum.ru/viewtopic.php?pid=395682#p395682

для Ъ

Почему это случилось теперь уже сказать трудно, но кроме ползователя рута новопоставленная 4-я Магея никого больше за своих признавать не хочет. То есть пользователи есть и похоже проверку они проходят, а вот с созданием сессий начинается полная ерунда:

Код: Выделить всё

21.02.14 18:22:06    localhostt    login    pam_tcb(login:auth): Authentication passed for human from LOGIN(uid=0)
21.02.14 18:22:06    localhostt    systemd-logind[761]    Failed to start unit user-500.slice: Transaction is destructive.

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

[Rootlexx]

я же говорю: kdm запускает иксы от рута, а потом перезапускает от юзера.

Вы неправы. Процесс X-сервера не перезапускается (зачем?), PID не меняется. Более того, при настройках по умолчанию KDM даже по завершении пользовательского сеанса не перезапускает X-сервер, а лишь делает сброс через SIGHUP.

Если (пере)запустить не удалось, kdm находится в состоянии "не жив и не мёртв". Вроде как в процессах есть, но его не видно, и "реагирует на команды" должно быть в кавычках, т.к. для ендюзера это чёрный экран смерти.

То, как это выглядит для пользователя, не относится к теме "Что и когда (пере)запускает X-сервер".
KDM же вполне штатно обрабатывает невозможность запуска X-сервера, просто отключая соответствующий display (это внутренняя структура KDM). Я могу утверждать это с уверенностью, ибо перелопатил значительную часть кода KDM в поисках причины этого бага. Подробности здесь: http://sources.debian.net/src/kde-workspac...dm/backend/dm.c.

В этой ситуации нужно лог читать, дабы узнать ПОЧЕМУ не запустились иксы. Ка и во всех остальных аварийных ситуациях. Для меня это очевидно, а вы продолжайте доказывать, что "kdmm висит в процессах, а значит Леннарт гений!".

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

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

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

Ну либо вы возвращайтесь к теме, и объясняйте мне, неразумному, чем в данной ситуации может помочь systemd. А то я этого по скудоумию не понимаю.

Вы удивитесь: ничем не может помочь. Ибо systemd здесь вообще не при чём. О чём я и говорил:

Я помню, когда это говнищще впихивали в Сузе было очень "весело" наблюдать, как оно висло, тупо пытаясь стартовать нестартующие иксы.

С каких это пор X'ы запускаются системой инициализации? Обычно система инициализации запускает дисплейный менеджер типа KDM, а тот уже стартует X-сервер.

Спасибо.

Пожалуйста.

[drBatty]

Процесс X-сервера не перезапускается (зачем?), PID не меняется.

процесс не перезапускается, PID не меняется, а вот сессия новая запускается.

То, как это выглядит для пользователя, не относится к теме "Что и когда (пере)запускает X-сервер".

да я знаю, что его на сегодня ничего не перезапускает. Я с этим и не спорю. Факт в том, что если иксы не поымутся, то systemd ничего не может поделать. Мало того, он будет думать, что "всё хорошо", т.к. kdm поднялся и висит. Ну а то, что юзер видит чёрный экран -- да, это к делу не относится (:

KDM же вполне штатно обрабатывает невозможность запуска X-сервера, просто отключая соответствующий display (это внутренняя структура KDM).

ага. Я так и думал. Ну и кому от этого легче?

В этой ситуации нужно лог читать, дабы узнать ПОЧЕМУ не запустились иксы. Ка и во всех остальных аварийных ситуациях. Для меня это очевидно, а вы продолжайте доказывать, что "kdmm висит в процессах, а значит Леннарт гений!".

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

я криво сказал, да, согласен. Это моя ошибка, сам Xorg действительно не перезапускается в том смысле, что процесс не отключается. Xorg закрывает сессию, и открывает новую, уже для юзера, а не для рута. И до этого я ошибся, сказав "kdm запускается внутри Xorg". Продолжайте прыгать от радости.

Лично меня эти мелочи волнуют мало, как и пользователей этих ваших иксов и kdm'а.

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

[Bizdelnick]

systemd здесь вообще не при чём

Как это Леннарт недоглядел? Надо срочно доработать systemd. Он везде должен быть причём!

[Rootlexx]

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

Верно. Это абсолютно корректное поведение, ибо X-сервер не является сервисом systemd и потому им не отслеживается.
Пользователь, кстати, будет видеть приглашение к логину в консоли. Не сахар, конечно, для неподготовленного пользователя, но тут уж вариантов немного.

Ну и кому от этого легче?

Надо полагать, никому. Но хочу подчеркнуть, что я оспаривал огульное обвинение systemd в том, что он-де перезапускает X-сервер до бесконечности, хотя запуском X-сервера вообще-то занимается не он. Утверждений, что systemd в данной ситуации будет чем-то лучше другой системы инициализации, у меня не было.
И даже если бы systemd действительно перезапускал X-сервер или KDM, это было бы лишь потому, что разработчики дистрибутива так настроили. По умолчанию, как я уже неоднократно указывал, сервисы автоматически не перезапускаются, а если кто-то вписал в сервис-файл Restart=always, это едва ли вина systemd, который в данной ситуации лишь выполнял бы то, что ему предписано администратором.

[drBatty]

Вы удивитесь: ничем не может помочь. Ибо systemd здесь вообще не при чём.

вот именно, не при чём. И тем не менее, я именно про этот ваш systemd и говорил. Остальное -- детали, которые к теме не относятся. И с трудом понимаю, о чём мы вообще спорим.

Ещё раз повторю те тезисы, которые я выдвигал: systemd никак не поможет в случае, когда иксы не подымутся. Мало того, у юзера будут проблемы с изучением логов и вообще причин, по которым у него всё сломалось. Процесс старта демонов и сервисов слишком сложен и уникален, что видно на примере иксов. И контролировать его каким-то внешним костылём конечно заманчиво, но невыполнимо.

С каких это пор X'ы запускаются системой инициализации? Обычно система инициализации запускает дисплейный менеджер типа KDM, а тот уже стартует X-сервер.

каких это пор лопатой кидают снег? Нет, говорят дворнику: "убери снег", тот берёт лопату, и убирает.

[drBatty]

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

это в теории. А вот практика: Переход Ubuntu на Systemd

он-де перезапускает X-сервер до бесконечности, хотя запуском X-сервера вообще-то занимается не он.

какая разница, прямо он этим занимается, или через KDM?

а если кто-то вписал в сервис-файл Restart=always, это едва ли вина systemd, который в данной ситуации лишь выполнял бы то, что ему предписано администратором.

в данном случае запускается KDM. И запускается "нормально", хоть и иксы не подымаются. Это, между прочим, обычный сценарий. Вот например proftpd тоже запускается. Но не весь, а только маленький кусочек, который подымает уже собственно сам сервер, когда юзер туда зайдёт. Это обычное дело.

[Rootlexx]

systemd никак не поможет в случае, когда иксы не подымутся.

Верно.

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

Это ещё почему? Наличие systemd не позволит прочитать /var/log/Xorg.0.log?

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

X-сервер не является ни демоном ни сервисом, поэтому никаким примером он не является.
Вот если бы X-сервер запускался как сервис systemd, тогда его можно было бы им контролировать.

С каких это пор X'ы запускаются системой инициализации? Обычно система инициализации запускает дисплейный менеджер типа KDM, а тот уже стартует X-сервер.

каких это пор лопатой кидают снег? Нет, говорят дворнику: "убери снег", тот берёт лопату, и убирает.

Что вы этим хотели сказать?

[Rootlexx]

это в теории. А вот практика

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

какая разница, прямо он этим занимается, или через KDM?

Разница в том, что в последнем случае этим занимается KDM, а не systemd. В этом случае вообще не важно, какая там система инициализации использовалась.
Если же рассматривать косвенное участие в запуске, то так и до ядра можно дойти.

[Rootlexx]

Как объяснить systemd, что в случае падения иксов нужно рестартовать DM?
То есть при падении одного сервиса нужно перезапускать другой сервис, не упавший, а как раз тот, который висит в процессах.

В том-то и дело, что X-сервер не запускается как сервис systemd. Это лишь дочерний процесс сервиса, и systemd в их взаимоотношения не вмешивается.
А вообще, для таких случаев есть зависимости. Конкретно в данном случае подойдёт Requires или PartOf в зависимости от того, что именно вы хотите (см. man systemd.unit).

[Hephaestus]

В том-то и дело, что X-сервер не запускается как сервис systemd. Это лишь дочерний процесс сервиса, и systemd в их взаимоотношения не вмешивается.

Вы уж простите, но мне почему это живо напомнило братьев Стругацких:

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

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

А вообще, для таких случаев есть зависимости. Конкретно в данном случае подойдёт Requires или PartOf в зависимости от того, что именно вы хотите (см. man systemd.unit).

Да вот неизвестно, подойдет или нет.
Статья Леннарта не затрагивает подобные случаи, стало быть, всегда есть вариант "Вам этого не обещали".
А вот на shell-скриптах, полагаю, эту задачу решить было бы можно.

[Rootlexx]

В том-то и дело, что X-сервер не запускается как сервис systemd. Это лишь дочерний процесс сервиса, и systemd в их взаимоотношения не вмешивается.

Вы уж простите, но мне почему это живо напомнило братьев Стругацких:

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

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

Вы сейчас серьёзно утверждаете, что было бы гораздо лучше, если бы systemd вмешивался туда, куда его не просили (не настроили) вмешиваться? Думаю, случись так, вы бы одним из первых возмущённо писали тут про systemd, который "себе на уме", который "лезет, куда не просят" и далее по списку.
Кроме того, представлять несанкционированное вмешательство в дерево процессов как критически важное качество, сродни способности ботинок работать в условиях сырости и пыли, мягко говоря, некорректно.

А вообще, для таких случаев есть зависимости. Конкретно в данном случае подойдёт Requires или PartOf в зависимости от того, что именно вы хотите (см. man systemd.unit).

Да вот неизвестно, подойдет или нет.
Статья Леннарта не затрагивает подобные случаи, стало быть, всегда есть вариант "Вам этого не обещали".
А вот на shell-скриптах, полагаю, эту задачу решить было бы можно.

Обзорная статья не является полноценной технической документацией. Пользуйтесь man-страницами.

[Hephaestus]

Вы сейчас серьёзно утверждаете, что было бы гораздо лучше, если бы systemd вмешивался туда, куда его не просили (не настроили) вмешиваться?

Нет. Было бы лучше, если бы в той же статье было четко указано: вот это systemd умеет и делает всегда, а вот это не делает и никогда не будет. Потому что "автоматический перезапуск сервисов" - это очень обширное понятие, и тот же kdm - вполне себе сервис, достойный автоматического перезапуска.
Но в статье нет таких вещей. Вместо этого там болтовня на 98 страниц с лозунгами и призывами, а что же это за зверь такой systemd, как не было понятно до прочтения статьи, так и осталось непонятно после прочтения.
Говоря коротко, непонятно, чего от него ждать. И по какой логике он работает - тоже непонятно.
Если статья не должна прояснить эти вопросы и нужно читать маны, тогда нахрен было разводить эту писанину на сотню страниц? Профессор Выбегалло - да и только.

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

[drBatty]

Это ещё почему? Наличие systemd не позволит прочитать /var/log/Xorg.0.log?

1. а залогинится нештатно разрешат?
2. а разве логи не бинарные?

X-сервер не является ни демоном ни сервисом

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

С каких это пор X'ы запускаются системой инициализации? Обычно система инициализации запускает дисплейный менеджер типа KDM, а тот уже стартует X-сервер.

каких это пор лопатой кидают снег? Нет, говорят дворнику: "убери снег", тот берёт лопату, и убирает.

Что вы этим хотели сказать?

то, что иксы запускаются инитом, хоть и не напрямую, а через kdm.

Причина проблемы не известна

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

[Rootlexx]

Было бы лучше, если бы в той же статье было четко указано: вот это systemd умеет и делает всегда, а вот это не делает и никогда не будет.

Что systemd умеет делать, описано в технической документации.
Если считаете, что в статье что-то недостаточно отражено, напишите автору свои предложения.

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

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

а что же это за зверь такой systemd, как не было понятно до прочтения статьи, так и осталось непонятно после прочтения.

А мне непонятно, почему вместо того чтобы воспользоваться традиционным средством получения документации в UNIX: man-страницами - вы начали со статей, сообщений на форумах и так далее, и, не разобравшись в предмете, пытаетесь спорить о нём. В том же man systemd есть секции Description и Concepts и ссылки на другие man-страницы - начните с них.

[Rootlexx]

а залогинится нештатно разрешат?

Если под "залогиниванием нештатно" подразумевается single-режим, то systemd его поддерживает. Штатный же вход в консоли никто не запрещает.

а разве логи не бинарные?

Шутить изволите?

• Xorg пишет в собственный текстовый файл журнала.
• Журнал выводится на экран в текстовом формате, а в каком виде это всё лежит на диске, в данном случае не важно.

X-сервер не является ни демоном ни сервисом

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

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

Причина проблемы не известна

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

Интересно, как моё "причина данной проблемы не известна" у вас превратилось в "АДМИНИСТРАТОР НЕ СМОЖЕТ ВЫЯСНИТЬ ПРИЧИНУ ПРОБЛЕМЫ!!!". Вы журналистом, случайно, не работали ?