- Помогите разобраться с plymouth-quit-wait. 20 секунд хватит всем?
- Проблема медленной загрузки из-за plymouth-quit-wait.service + ubuntu 18.04
- 1 ответ
- Медленная проблема начальной загрузки из-за plymouth-quit-wait.service + человечность 18.04
- 3 ответа
- Ускорение загрузки Linux
- Как проходит загрузка Linux
- Анализ загрузки Systemd
- Ускорение загрузки Linux
- Настройка системы
- Ускорение загрузки Linux отключением сервисов
- Выводы
Помогите разобраться с plymouth-quit-wait. 20 секунд хватит всем?
Видно, что фейлится по таймауту. Смотрим .service файл:
20 секунд. Отлично. Меняем на 120, перезагружаемся, и в итоге:
В связи с чем есть пару вопросов:
1. Для чего используется этот таймаут? Таким образом какой-то баг пофиксили или что?
2. Почему именно 20 секунд?
Пальцем вы небо, возможно, таймаут нужен для systemd, он же «умный» запускается сервисы (юниты) параллельно, может какой-то не успевает отработать, вот и поставили таймаут, что бы это как-то работало.
Я бы ещё понял, если бы это была задержка перед запуском службы (ну мало ли). Но нет, 20 секунд — это максимальное время, которое отводится на её запуск (и работу по сути).
А вот и коммит на freedesktop.org. Только я всё равно ничего не понимаю. 🙁
plymouth-quit-wait — сервис, который ждёт завершения Plymouth. Он нужен исключительно для того, чтобы программы, работающие с графикой (в частности, иксы) запускались после plymouth и не конфликтовали за фреймбуфер.
Таймаут здесь служит для того, чтобы система смогла запуститься, если Plymouth сломается/зависнет или по иным причинам не сможет отправить процессу plymouth-quit-wait сигнал о своём завершении (там D-Bus и всё такое).
Похоже так и есть. Но тогда есть другой вопрос.
Что происходит в этом случае? plymouth-quit-wait фейлится, а что дальше? Получается, кто-то должен убить зависший plymouthd?
Ну да, по идее, дальше требуется человеческое вмешательство (свитчнуться в консоль, посмотреть логи и починить/снести plymouth).
Кстати, в systemd у всех юнитов есть неявный таймаут в 90 секунд. Здесь просто сделали меньше — видимо, оно часто падает 🙂
дальше требуется человеческое вмешательство
В моём случае оно требуется постоянно. Но всё же меня смущает старт GDM’а даже в случае фейла службы plymouth-quit-wait. Причём всё происходит без ошибок.
у всех, кроме имеющих тип «oneshot», юнитов есть неявный таймаут в 90 секунд
Справедливости ради фикс.
Defaults to 90s, except when Type=oneshot is used in which case the timeout is disabled by default.
у всех, кроме имеющих тип «oneshot», юнитов есть неявный таймаут в 90 секунд
Справедливости ради фикс.
Хм, и действительно. Надо читать маны, а не цитировать на память 🙂
Кстати, насколько понимаю, у Fedora GDM должен быть пропатчен на взаимодействие с Plymouth.. Попробуй включить gdm-plymouth.service вместо gdm.service (если ты ещё не).
у Fedora GDM должен быть пропатчен на взаимодействие с Plymouth
Ну да, он собран с флагом «—with-plymouth». gdm.spec:
Собственно в таком случае сам GDM следит за завершением работы Plymouth. Например, там есть такие строки:
В Fedora gdm.service не сильно отличается от gdm-plymouth.service из AUR:
Не думаю, что здесь что-то имеет решающее значение. Кроме того, пользователи Arch’а тоже жаловались на эту проблему.
Источник
Проблема медленной загрузки из-за plymouth-quit-wait.service + ubuntu 18.04
Это недавно установленная машина, работающая в режиме двойной загрузки поверх Win 10. При каждой перезагрузке машина зависает на 15 секунд, так как служба plymouth не может запуститься по некоторым причинам.
Ниже приведен фрагмент вывода systemd-analysis
Вот несколько фрагментов загрузочных логов
Установлен графический драйвер последней версии — 415 из репозитория ppa
Можете ли вы сообщить мне, почему происходит задержка из-за службы plymount-quit? Пожалуйста, дайте мне знать, есть ли какая-либо другая информация, которая вам потребуется для устранения неполадок?
Это связано с проблемой аппаратного / программного / графического драйвера?
1 ответ
Вы можете отключить эту службу, выполнив команду:
Из описания сервиса:
Удерживайте до завершения процесса загрузки
Плимут не замедляет процесс загрузки! Плимут отвечает за заставку загрузки. Пожалуйста, прочитайте здесь.
Он загружает логотип загрузки в начале процесса загрузки и затем ждет, пока процесс загрузки не завершится, поэтому он выгружает заставку. Это все, что он делает, и поэтому он должен работать параллельно и сосуществовать в течение всего процесса загрузки. Это ничего не задерживает, просто ждет.
Это именно то, что происходит. Не больше и не меньше. Пожалуйста, ознакомьтесь с результатами, которые вы добавили к своему вопросу, и внимательно прочитайте следующее:
● plymouth-quit-wait.service — удерживайте до завершения процесса загрузки
Чтобы понять больше.
Пожалуйста, выполните следующую команду в терминале:
Затем ищите SystemdAnalyzePlot.svg в вашем домашнем каталоге и запустите его в программе просмотра изображений или в интернет-браузере. Возможно, вам придется увеличить изображение, чтобы вы могли прочитать имена процессов. Это стоит проверить и даст вам лучшее понимание того, как работает процесс загрузки.
Однако вы можете сократить время загрузки, отключив NetworkManager-wait-online.service так что у Плимута есть на один процесс меньше, чтобы ждать. Это действительно может сократить время загрузки. Чтобы сделать это, пожалуйста, следуйте инструкциям в этом ответе.
Ох. и, пожалуйста, оставьте Плимут в покое, это не то, что заставляет вас ждать. это то, что ждет вас
Источник
Медленная проблема начальной загрузки из-за plymouth-quit-wait.service + человечность 18.04
Это — недавно установленная машина, работающая как двойная загрузка по Win 10. Для каждой перезагрузки машина зависает для 15 secs как плимутский сервис, не могущий запускаться, из-за некоторых причин.
Ниже systemd-проанализировать выходной отрывок
Вот являются некоторые отрывком журналов начальной загрузки
Графический драйвер установил последнюю версию — 415 из ppa репозитория
Можно ли сообщить мне, почему существует задержка, происходящая должный plymount-выйти из сервиса? Сообщенный мне там какая-либо другая информация, которой Вы потребовали бы для поиска и устранения неисправностей?
Это связано с аппаратными средствами / программное обеспечение проблема драйвера/grahics?
3 ответа
Я не могу сказать, что еще необходимо, но я могу, возможно, дать обходное решение для Вас, так, чтобы машина запустилась быстрее.
Для меня самое рабочее решение состояло в том, чтобы отключить Плимут в личинке с
и измените строку GRUB_CMDLINE_LINUX_DEFAULT в
После сохранения изменения необходимо обновить личинку с
и затем перезапустите машину.
Можно отключить этот сервис путем выполнения команды:
Из сервисного описания:
Держите, пока процесс начальной загрузки не заканчивается
Плимут не замедляет Ваш процесс начальной загрузки! Плимут ответственен за экран-заставку начальной загрузки. Читайте здесь.
Это загружает логотип начальной загрузки в начале процесса начальной загрузки и затем ожидает, пока процесс начальной загрузки не закончился так, это разгружает экран-заставку. Это — все, что это делает и именно поэтому это должно работать параллельно и сосуществовать в течение целого процесса начальной загрузки. Это ничего не задерживает, это просто ожидает.
Это точно, что происходит. Не больше и не меньше. Смотрите на вывод, который Вы добавили к своему вопросу, и тщательно считайте следующее:
● plymouth-quit-wait.service — Содержат, пока процесс начальной загрузки не заканчивается
Понять больше.
Выполните следующую команду в терминале:
Затем ищите SystemdAnalyzePlot.svg в Вашем корневом каталоге и выполненный это в программе просмотра изображений или интернет-браузере. Вы, возможно, должны были бы увеличить изображение так, чтобы можно было считать имена процессов. Это стоит проверить и даст Вам лучшее понимание того, как процесс начальной загрузки работает.
Можно, однако, уменьшить время начальной загрузки путем отключения NetworkManager-wait-online.service таким образом, Плимут имеет тот меньше процесса для ожидания. Это может действительно уменьшить Ваше время начальной загрузки. Чтобы сделать это, выполните шаги в этом ответе.
О. и оставьте Плимут в покое, это не то, которое заставляет Вас ожидать. это — то, которое ожидает Вас
Источник
Ускорение загрузки Linux
Скорость загрузки вашей операционной системы — это очень важный момент в работе компьютера. Никому не хочется смотреть на заставку загрузки по несколько минут. Чем быстрее загрузится система и будет готова к работе, тем лучше.
Но порой система инициализации выполняет много лишних задач во время загрузки, иногда некоторые сервисы ожидают загрузки других и завершаются только по таймауту через некоторое время. В таких случаях система может загружаться до нескольких минут. В этой статье мы рассмотрим как ускорить загрузку Linux, что нужно для этого настроить, что удалить. А также немного поговорим о процессе загрузки. Мы сосредоточимся на системе инициализации systemd.
Как проходит загрузка Linux
Во всех подробностях процесс загрузки Linux описан в отдельной статье, здесь же мы рассмотрим только то, что будет касаться ускорения.
На то как BIOS тестирует устройства и запускает загрузчик мы повлиять не можем. Работу загрузчика тоже ускорить не получится, можно только убрать ожидание выбора пункта меню.
Но самое интересное начинается дальше. Перед тем как начать загрузку системы ядро выполняет несколько проверок, загружает модули и так далее. Не все проверки нужно выполнять и не все модули нам нужны.
После того как ядро передало управление системе инициализации, начинается монтирование дисков. Это тоже отнимает время, лучше не использовать виртуальные разделы дисков, например, raid или lvm, да и вообще, чем меньше разделов — тем лучше. Идеальный вариант — только корневой раздел, тогда скорость загрузки linux будет максимальной. Но это очень невыгодный в плане удобства вариант, поэтому найдите золотую серединку. Перед тем как примонтировать каждый диск, система инициализации пытается проверить файловую систему на ошибки, это тоже замедляет загрузку.
Загрузка сервисов отнимает больше всего времени и больше всего работы придется проделать здесь, определить какие сервисы не нужны и отключить их также скрыть те сервисы, которые отключить нельзя. Чтобы понять что именно отключать нам нужно знать сколько времени занимает загрузка каждого сервиса. Давайте рассмотрим анализ скорости загрузки systemd.
Анализ загрузки Systemd
Анализ скорости загрузки системы важен не только в самом процессе оптимизации, но и для того, чтобы оценить насколько эта оптимизация удалась. Перед и после оптимизации нужно замерять время загрузки, чтобы понять чего мы смогли добиться.
Давайте посмотрим насколько быстро грузится наша система сейчас:
Да, здесь 17 секунд, не так уж плохо, но будет еще лучше после завершения ускорения загрузки. На загрузку ядра уходит 5.405, а на все остальные сервисы 11.611. Чтобы понять какие именно сервисы замедляют систему нам нужна более подробная информация, мы можем ее получить с помощью параметра blame:
У нас есть список сервисов, которые загружаются дольше всего, но этот список ни о чем нам не говорит, потому что в Systemd параллельная загрузка сервисов. Если бы во время загрузки была какая-нибудь проблема, мы бы ее увидели, но проблем здесь нет. Нам нужен более детализованный график с указанием не только времени загрузки сервиса, но и с отображением параллельных загрузок и мы можем его получить командой:
systemd-analyze plot > graph.svf
Утилита сгенерирует svf файл с графиком, откройте его в браузере:
Вот теперь у нас есть вся информация, чтобы оптимизировать систему. Здесь отображается не только время загрузки каждого сервиса, но также время когда он начал загружаться и когда завершил. Дальше начнем ускорение загрузки Linux.
Ускорение загрузки Linux
Начнем мы с оптимизации ядра 5 секунд, это не так много, но можно же еще улучшить. Мы не будем пересобирать ядро, хотя и это дало бы больший эффект, мы просто настроим его работу с помощью параметров загрузки.
Настраивать Grub будем правильно. Параметры загрузки ядра находятся в файле /etc/default/grub, а именно в строчке GRUB_CMDLINE_LINUX_DEFAULT. Откройте этот файл:
Теперь приводим интересующую нас строчку к такому состоянию:
GRUB_CMDLINE_LINUX_DEFAULT=»quiet rootfstype=ext4 libahci.ignore_sss=1 raid=noautodetect selinux=0 plymouth.enable=0 lpj=12053560″
Разберем подробнее за что отвечает каждый параметр:
- quiet — вывод, это долго, поэтому говорим ядру что на экран нужно выводить минимум информации
- rootfstype=ext4 — указываем в какую файловую систему отформатирован корень. У меня ext4.
- libahci.ignore_sss=1 — Ignore staggered spinup flag, ускоряет загрузку жестких дисков
- raid=noautodetect — raid я не использую, думаю вы тоже поэтому отключаем.
- selinux=0 — система полномочий selinux на домашней машине тоже ни к чему, без нее будет быстрее.
- plymouth.enable=0 — заставка plymouth тоже занимает много времени, поэтому убираем заставку
- lpj=12053560 — позволяет задать константу loops_per_jiffy, что позволит ядру не вычислять ее каждый раз и сэкономит до 250 миллисекунд. Это значение индивидуально для каждого компьютера.
Чтобы узнать значение последнего параметра выполните:
dmesg | grep ‘lpj=’
Нас будет интересовать значение lpj=, укажите его в своем конфигурационном файле.
Также для указания корневого раздела желательно не использовать всякие там UUID, быстрее будет если написать прямо. Для того чтобы конфигуратор grub не использовал grub добавьте в тот же файл строчку:
Сохраните файл и обновим конфигурацию grub:
Проверяем, действительно ли установлены нужные опции:
Да, все правильно, перезагружаем компьютер, и смотрим что вышло:
Почти на одну секунду быстрее, и то хорошо. Возможно, у вас эффект будет намного лучше. Теперь идем разбираться с сервисами.
Настройка системы
Во-первых SELinux отключен не полностью. Для полного отключения добавляем строку в файл /etc/selinux/config:
sudo vi /etc/selinux/config
Во-вторых, проверка файловых систем тоже может занять некоторое время. Оставляем проверку на ошибки только для корня. Для этого откройте файл /etc/fstab и приведите строчку для корня к такому виду:
/dev/sda3 / ext4 defaults 1 1
Последний параметр отвечает за проверку, 1 — проверять, 0 — не проверять. Установите для всех других разделов 0. К тому же boot раздел лучше монтировать по требованию. Для этого изменяем его запись:
/dev/sda1 /boot ext4 noauto,comment=systemd.automount 1 0
Затем давайте перенесем папку /tmp в оперативную память, чтобы уменьшить количество операций на жестком диске:
tmpfs /tmp tmpfs defaults 0 0
Ускорение загрузки Linux отключением сервисов
Вот мы и добрались к сервисам. Оптимизация сервисов заключается в том, чтобы отключить лишнее, а также использовать только возможности, встроенные в systemd, так будет быстрее. Сначала перенесем всю функциональность на systemd.
Первым отключим rsyslog. В systemd используется свой механизм записи логов journald, поэтому вести еще один не нужно. Для отключения выполните:
sudo systemctl disable rsyslog
$ sudo systemctl mask rsyslog
Опция mask позволяет спрятать юнит, система будет думать что его не существует и не сможет загрузить. Восстановить такой юнит можно командой systemctl unmask.
В systemd реализована своя служба настройки сети — networkd, поэтому необязательно использовать NetworkManager. Работа со встроенной службой будет намного быстрее. Здесь нужно заметить, что если вы используете wifi и не хотите настраивать его вручную, через консоль, то отключать NetworkManager не стоит.
Отключаем NetworkManager и включаем networkd:
sudo systemctl disable NetworkManager
sudo systemctl enable systemd-networkd
Службу networking тоже можно отключить, если не используете:
sudo systemctl disable networking
Включаем resolved, который отвечает за настройку DNS серверов:
sudo systemctl enable systemd-resolved
sudo systemctl start systemd-resolved
Даем символическую ссылку на файл /etc/resolv.conf
sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Осталось настроить динамическое получение ip адреса при загрузке:
sudo vi /etc/systemd/network/20-dhcp.network
[Match]
Name=enp*
[Network]
DHCP=yes
enp0* значит, что сеть нужно подымать только для устройств, имена которых начинаются на enp0. Готово, сеть настроена.
В systemd есть свое решение для выполнения задач по расписанию, поэтому cron можно не использовать:
sudo systemctl disable cron
С заменой разобрались, перейдем к удалению лишнего. Отключаем фаервол, на домашней машине, за маршрутизатором он не нужен:
sudo systemctl disable ufw
$ sudo systemctl mask ufw
Отключаем apport (служба отчетов об ошибках):
sudo systemctl disable apport
Я не использую ppp и мобильные соединения, поэтому и эти сервисы можно отключить.
sudo systemctl disable pppd-dns
sudo systemctl mask pppd-dns
sudo systemctl disable ModemManager
sudo systemctl mask ModemManager
Если вы не используете Avahi, его тоже можно отключить:
sudo systemctl disable avahi-daemon
Систему AppArmor тоже можно отключить:
sudo systemctl disable apparmor
Также если у вас загружаются такие программы, как postfix (почтовый сервер), apache (веб-сервер), mysql (сервер баз данных) лучше их тоже убрать из автозагрузки и запускать потом вручную.
Перезагружаемся и проверяем скорость загрузки:
У меня скорость загрузки linux выросла на пять секунд. Но это нормально, учитывая, что используется VirtualBox, на реальной машине можно получить и больше. А самая лучшая оптимизация — купить SSD, там можно достичь даже скорости загрузки до двух-трех секунд.
Выводы
Вот и все, в этой статье мы рассмотрели как ускорить загрузку Linux. Если у вас долго грузится Linux вы уже знаете что нужно делать. Если вы знаете другие способы ускорить загрузку Linux, напишите в комментариях!
Источник