Долго запускается система из-за dhcpcd@.service, man-db.service и большого лога systemd

Всем привет!
Многие наблюдали как эти две службы тормозят загрузку системы:
До
Исправляем это.
Отключаем переодическое увеличение загрузки из-за man-db.service
Взято отсюда
Нужно создать два файла (если таких директорий нет, то тоже их создаём)
Создаём директории:
sudo mkdir -p /etc/systemd/system/man-db.timer.d
Сам файл, с содержимым:
sudo nano /etc/systemd/system/man-db.timer.d/man-db.timer.conf
[Timer]
OnCalender=
OnCalendar=20:00
OnBootSec=120

sudo mkdir -p /etc/systemd/system/updatedb.timer.d
sudo nano /etc/systemd/system/updatedb.timer.d/updatedb.timer.conf
[Timer]
OnCalender=
OnCalendar=20:05
OnBootSec=180

dhcpcd@.service тормозит загрузку системы
Статья Wiki
Это происходит потому, что hcpcd@.service ждёт получения ip-адреса, а потом запускается дальше. Исправим это поведение:
sudo mkdir -p /etc/systemd/system/dhcpcd@.service.d/
sudo nano /etc/systemd/system/dhcpcd@.service.d/no-wait.conf
С таким содержимым:
[Service]
ExecStart=
ExecStart=/usr/bin/dhcpcd -b -q %I

Система долго запускается... еще одна причина в разросшемся логе systemd.
1 Вариант решения.
По умолчанию лог может занимать до 10% от размера раздела диска, где находится /var
Т.е. Если раздел 10 гб, то и лог расти может до 1 гб)
Если Вам не нужны прошлогодние и позапрошлогодние логи, и медленный запуск, - вариант, уменьшить размер для лога systemd

sudo nano /etc/systemd/journald.conf
Найти и расскоментировать строчку, добавив значение, к примеру 5М - т.е. ограничим размер лога 5 мегабайтами (в среднем после каждой загрузки системы, лог увеличивается на 700 кб)
SystemMaxUse=5M

2 Вариант решения борьбы с большим журналом Systemd
Просто выполним команду:
journalctl --vacuum-size=5M
Эта команда ограничит размер журнала, удалив старую, не актуальную инфу.

После
P.S. В три раза быстрее (размер журнала у меня ограничен сразу после установки, зачастую он самый большой "ручник") :-)
P.S.S такое ощущение, что системд это некая лохматая лапа а-ля MS, признанная включить ручник на Линуксах... надеюсь я не прав.
Русская команда переводчиков ArchWiki
скромный вклад
man-db.timer я вообще маскировал:
$ systemctl status man-db.timer
● man-db.timer
   Loaded: masked (/dev/null; masked)
   Active: inactive (dead)
  Trigger: n/a
Запускаю руками mandb после обновлений.

С dhcpcd@.service на установленных арчах такой траблы у меня нет (сервис не запускается на старте), а вот при запуске в Live_Archiso присутствует.
---
В целом, спасибо за работу! У меня все руки не доходили... )
Пива много не бывает.
Aivar
Ну этот то понятно, но вы зачем??
Там по умолчанию в timer стоит один раз в день. Шанс нарваться на это 30 сек. обновление составляет 1 к ~2000, ну это если вы каждую секунду будет перезагружать компьютер, если просто будете работать в течении дня и перезагружать раз в день(а то и в месяц, год) шанс стремиться к нулю.

а dhcpcd я бы так делать не советовал, так как он специально не уходит в background дожидаясь получения ip и уже после этого нормального запуска сервисов в которых есть зависимость от этого.

p.s. да как-то был период когда man-db что-то маячил, но это было давно и неправда, сейчас никаких проблем при нормальном использовании быть не должно.
Ошибки в тексте-неповторимый стиль автора©
я вместо dhcpcd@.service использую systemd-networkd.service, перешел как раз из за тормозов при подключении.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
indeviral
зачем
Мне вот не понятно зачем вообще обновлять базы манов по таймеру, когда логичнее это делать после обновления ( или вручную или прописав в конфиг пакмана)
А вообще вспоминается убунта там тоже при настройке надо было отключать кучу не всем нужных сервисов. С приходом системд это теперь и в арче.

malody
После
lvm2-monitor.service 880ms
если lvm не используется тоже можно замаскировать
vs220, можно же доказать что это ну нужно и разрабы уберут.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
vs220
Мне вот не понятно зачем вообще обновлять базы манов по таймеру
это сделано чтобы поддерживать man в актуальном состоянии, в не зависимости от частоты обновления и тп.

nafanja
можно же доказать что это ну нужно и разрабы уберут.
это оптимальный способ, man к сожалению никак не завязан на версии пакетов в целом и тем более на версии пакетов от майнтейнеров.
p.s. ну на сколько я знаю...
Ошибки в тексте-неповторимый стиль автора©
indeviral
это сделано чтобы поддерживать man в актуальном состоянии, в не зависимости от частоты обновления и тп.
Вот тут и вопрос, маны изменяются при установке программы или ее обновлении. То есть сейчас мы получим устаревшую базу при обновлении если обновлялись
после отработки таймера. И если не обновлялись не устанавливали пакеты то и базы нет смысла обновлять.
Лично мне удобнее когда mandb отрабатывает в фоне после обновления, а не при старте системы когда диск и так нагружен
А многие вообще поиском в манах не пользуются и зачем им таймер. Понадобилось переиндексировал базу добавив вызов в алиасы
vs220
маны изменяются при установке программы или ее обновлении
неа, они обновляются абсолютно произвольно, в том и дело (зависит от желания разработчиков и переводчиков)...
вообщем всё конечно индивидуально, но советовать отключать или что-то менять в данном случаи это неправильно.
Ошибки в тексте-неповторимый стиль автора©
indeviral
они обновляются абсолютно произвольно
???
пакет программы содержит ман usr/share/man

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