Тред ненависти к systemd-analyze

Ну и как он поймёт внутреннюю логику бинарника. strace -T

Мне не надо чтобы кто-то понимал внутреннюю логику бинарника, мне нужно просто чтобы в critical path было написано, что sysinit.target 2 минуты ждет такой-то сервис. Иначе какой это нахрен critical path?

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

Пришёл сказать, что курить надо не графики, а логи, но, как оказалось, уже отписались.

ТС, ты ещё попробуй зубы удалять через задницу. journalctl прекрасно кажет, кто в чём виноват, а systemd-analyze — это просто график загрузки, надеяться на его информативность не следует.

journalctl прекрасно кажет, кто в чём виноват

Что он там «кажет» кроме обыкновенных логов?

journalctl прекрасно кажет, кто в чём виноват

Что он там «кажет» кроме обыкновенных логов?

Такой большой дядя, а логи читать не научился? Ладно, продолжай ныть, а я пойду.

Если сам сервис в лог ничего не пишет, то ничего ты там и не увидишь. Давай, до свидания.

Все сервисы systemd в лог пишут, а если у тебя fstab, то это работа systemd, и генерированных mount-сервисов, так что или мейнтейнеры твоего дистра криворуки, или ты сам. Второе более вероятно.

Кстати, всегда с новостью про systemd обычно на ЛОРе появляется пара-тройка нытик-тредов. Для контрастности, да?

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

Блин. Openrc вот просто пишет, чо оно грузит. В системд это не так штоле?

Всё там так. Просто некоторые уникумы не знают, как привлечь к себе внимание.

Ну чувак вот пишет, что не т нихрена.

Так дело в том, что он грузит сервисы не последовательно, а параллельно. Даже если бы он писал в лог что именно он в данный момент грузит, это бы не помогло. В лог он выплевывает ошибки, если они есть. Но изначальная претензия то не в этом, а в том, что есть долгое время загрузки и есть специальный инструмент, который предназначен для определения почему так получается (он потому и необходим, что загрузка сервисов параллельная), но он найти причину почти никак не помогает, а скорее вводит в заблуждение.

openrc тоже может параллельно грузить, и без этой хуйни работает.

Если "чувак" не хочет, то оно и не заработает.

Видишь ли, этот тред выглядит не как просьба о помощи, а как нытьё, направленное на расширение их, хейтерской, банды, приуроченный к выходу очередной версии.

Я не говорю, что systemd хорош, в чём-то он действительно сливает тому же OpenRC, особенно, когда дело касается отлова бажных сервисов, но для конечного пользователя он вполне себе альтернатива. Если грамотно настраивать софт, то он будет работать как надо.

Видишь ли, этот тред выглядит не как просьба о помощи

Это и не просьба о помощи, если ты с самого начала не заметил - проблема была решена ещё до появления треда.

есть специальный инструмент, который предназначен для определения почему так получается

вообще не предназначен.

Специально для тупых в мане написано:
systemd-analyze blame prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. *Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete.*

для тупых
в мане

/0 Тупые не читают маны, знаешь ли.

Специально для тупых в мане написано:
systemd-analyze blame ... This information may be used to optimize boot-up times

Ты чего в эту тему влез? По-английски читать умеешь? Ты в курсе, что кроме blame у systemd-analyze есть ещё несколько команд?

Ты дальше читай, умник. Я тебе специально выделил, как слабовидящему.
Ни одна из команд systemd-analyze не предназначена для того, чего ты хочешь и *нигде* в мане не указано обратное.
Вот ты по-англицки читать явно не умеешь, раз не знаешь, чем may от can отличается.

sysinit.target ждет своей очереди 2 минуты только потому, что в /etc/fstab указан неправильный UUID swap-раздела

Смоделировал ситуацию на Fedora 24 — задержки нет.
Вам следует попинать мейнтейнера в своём дистре.

Ни одна из команд systemd-analyze не предназначена для того, чего ты хочешь и *нигде* в мане не указано обратное.

Ты не понимаешь ни сути проблемы, ни предназначения systemd-analyze, поэтому несешь феерический бред.

Вот ты по-англицки читать явно не умеешь, раз не знаешь, чем may от can отличается.

Мальчик, иди со своими комплексами отсюда подальше. Глагол «may» в данном контексте как раз и указывает на предполагаемое разработчиками применение.

Смоделировал ситуацию на Fedora 24 — задержки нет.
Вам следует попинать мейнтейнера в своём дистре.

Так ты смоделируй ситуацию чтобы была задержка, а потом попробуй найти причину. Проблема же не в конкретном свопе, а в systemd-analyze.

Так ты смоделируй ситуацию чтобы была задержка

Универсальный рецепт есть?

Ну, возможно, написать shell-скрипт со sleep 120 и воткнуть его завершение условием для старта sysinit.target (или кто там вместо него в федоре)?

Ясно, читать не умеешь, англицкого не знаешь, зато самый умный, да.
Мальчиками ты одноклассников своих называть будешь, «дядя».

Ясно, читать не умеешь, англицкого не знаешь

Ты идиот что ли? Что по-твоему там написано???

Там англицким по белому писано: systemd-analyze предназначен для *статистики* а не поиска проблем (кроме systemd-analyze verify). systemd-analyze blame/critical-chain *не показывает* причину задержки юнита.
Еще вопросы?

inb4: проблема и причина проблемы - разные вещи.

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

Смотри «Фатальный недостаток».

Там англицким по белому писано: systemd-analyze предназначен для *статистики* а не поиска проблем

Мда, прямо вот так и написано: «для *статистики* а не поиска проблем ... *не показывает* причину задержки юнита»? Привет вам там, в альтернативной реальности.

Да, прям так и написано: systemd-analyze may be used to determine system boot-up performance statistics
Ты до сих пор не привел ничего, чтобы доказывало обратное.

Проходишь в игнор со своей пустопорожней болтовней.

Что и требовалось доказать.