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

vs220
Как локальный ман программы обновится без обновления пакета программы?
никак, но вот собрать пакет в котором будет отличаться только usr/share/man это запросто))
ну не индексировать же базу после установки одного пакета?)
Ошибки в тексте-неповторимый стиль автора©
indeviral
ну не индексировать же базу после установки каждой программы?)
По уму именно так.Я например ставлю программы реже чем раз в день и ежедневный таймер мне не нужен. На паре программ mandb отрабатывает за секунду. Вас же не смущает индексация базы пакмана при каждом обновлении.

Но все это конечно индивидуально кому как удобней. Я стараюсь запускать сервисы по мере их необходимости. А то так дойдем как на винде хочешь выключить подожди пока обновления установятся
indeviral
они обновляются абсолютно произвольно
Но не чаще чем я обновляюсь. А обновляюсь я пару раз в месяц, загружаюсь раз в день. Зачем мне каждый день шкрябать винтом, тем более
vs220
при старте системы когда диск и так нагружен
?

indeviral
как-то был период когда man-db что-то маячил, но это было давно и неправда, сейчас никаких проблем при нормальном использовании быть не должно.
Вот когда mandb отрабатывал пару минут, тогда я таймер и маскировал, и, судя по дате создания симлинка, было это не так давно:
$ stat -c %y /etc/systemd/system/man-db.timer
2017-04-11 21:19:10.319369390
vs220
Мне вот не понятно зачем вообще обновлять базы манов по таймеру, когда логичнее это делать после обновления ( или вручную или прописав в конфиг пакмана)
Да, я тоже ломал голову, зачем так сделали.
Такой рецепт был бы полезен:
замаскировать или отключить man-db.timer (не помню, что там с ним можно сделать);
добавить какой-нибудь хук для pacman, что если пакеты устанавливались/ удалялись, то запустить mandb
Update. Оказывается, что этот очевидный рецепт не только существовал, но и на него реально переходили разработчики man-db! Но после того, как стали поступать жалобы на задержки после обновлений, вернулись обратно на чистый таймер.
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/man-db&id=3cc9b65d0e2d69f1735c15e58a1391a14f696472
Комментарий к первому посту.

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

1) В заголовке пишите про две службы: dhcpcd@.service и man-db.service
На самом деле меняете настройки двух таймеров и одной службы.
На какие настройки меняете таймер - тоже новичку непонятно.

2) Таймер updatedb.timer - ни к man-db, ни dhcpcd отношения не имеет.
Между тем, это таймер из пакета индексации файлов mlocate. Если вам не нужна индексация всех файлов в системе, то пакет можно вообще удалить, и настраивать таймер не нужно будет.

3) Редактировать настройки служб systemd можно (и удобней) не вручную, а с помощью самой systemd:
- посмотреть настройки
systemctl cat man-db.timer
- отредактировать (будет создан drop-in)
systemctl edit man-db.timer
и потом еще раз проверяем, что все правильно.
не замечал что бы эти сервисы как то себя проявили, что бы стоило их выключить или перенастроить.
работают в фоне. никого не тормозят. почему бы им не жить как задумано?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
не замечал что бы эти сервисы как то себя проявили, что бы стоило их выключить или перенастроить.
Меняешь SDD на HDD и сразу начинаешь замечать, особенно когда systemd-analyze пишет, что время загрузки системы 2m 15s, две минуты из которых - man-db.service :-/
Во всяком случае так было год назад.
Aivar, можешь вспомнить, графическая оболочка тоже не загружалась 2 минуты?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
Нет, конечно, но общее впечатление портило.
nafanja
не замечал что бы эти сервисы как то себя проявили, что бы стоило их выключить или перенастроить.
работают в фоне. никого не тормозят. почему бы им не жить как задумано?
Давай попробуем разобраться. Насколько я понимаю, таймер срабатывает только один раз в сутки в 00:00, а если комп был выключен, то при 1-ой загрузке, в которую и тратится лишнее время на обработку справочных страниц/записей, но это время зависит от наличия и объема обновления базы данных после последнего запуска таймера (т. е. если обновлений не было, то и обрабатывать нечего).
Привожу для примера свой вывод за сегодняшнее 1-ое включение
journalctl -u man-db -b -7
июн 24 00:12:49 arch systemd[1]: Starting Update man-db cache...
июн 24 00:12:55 arch mandb[382]: Обновление индексного кэша для пути `/usr/share/man/man8'. Ждите...
июн 24 00:12:55 arch mandb[382]: Удаление старых записей базы данных в /usr/share/man...
июн 24 00:12:55 arch mandb[382]: Обработка справочных страниц в /usr/share/man...
июн 24 00:12:55 arch mandb[382]: /usr/bin/mandb: предупреждение: /usr/share/man/man8/numastat.8.gz: whatis анализ numastat>
июн 24 00:12:56 arch mandb[382]: Обновление индексного кэша для пути `/usr/share/man/man5'. Ждите...
июн 24 00:12:56 arch mandb[382]: Обновление индексного кэша для пути `/usr/share/man/man7'. Ждите...
июн 24 00:12:57 arch mandb[382]: Обновление индексного кэша для пути `/usr/share/man/man1'. Ждите...
июн 24 00:12:58 arch mandb[382]: /usr/bin/mandb: предупреждение: /usr/share/man/man1/mjpegtools.1.gz: whatis анализ mjpegt>
июн 24 00:12:59 arch mandb[382]: завершено.
июн 24 00:13:02 arch mandb[382]: Проверка побочных cat в /usr/share/man...
июн 24 00:13:02 arch mandb[382]: Проверка побочных cat в /var/cache/man...
июн 24 00:13:02 arch mandb[382]: Удаление старых записей базы данных в /usr/share/man/ja...
июн 24 00:13:02 arch mandb[382]: Обработка справочных страниц в /usr/share/man/ja...
июн 24 00:13:02 arch mandb[382]: Удаление старых записей базы данных в /usr/share/man/hu...
июн 24 00:13:02 arch mandb[382]: Обработка справочных страниц в /usr/share/man/hu...
июн 24 00:13:02 arch mandb[382]: Удаление старых записей базы данных в /usr/share/man/sv...
июн 24 00:13:02 arch mandb[382]: Обработка справочных страниц в /usr/share/man/sv...
июн 24 00:13:02 arch mandb[382]: Удаление старых записей базы данных в /usr/share/man/de...
……. и так далее ….. привожу концовку …..
июн 24 00:13:03 arch mandb[382]: Добавлено 177 справочных страниц.
июн 24 00:13:03 arch mandb[382]: Добавлено 0 побочных cat-страниц.
июн 24 00:13:03 arch mandb[382]: Вычищена 1 старая запись базы данных.
июн 24 00:13:03 arch systemd[1]: Started Update man-db cache.[
Откуда считать? допустим от самого старта mandb 00:12:49 и конец 00:13:03 - т. е. 14с. Разумеется, чем больше перерыв между обновлениями и больше объем, тем больше будет обработано страниц/записей и будет больше затрачено времени.
Посмотрел логи за другие даты - в одном из логов время было более 1 мин (было большое обновление и было добавлено порядка 1000 справочных страниц).
Вывод - каждый решает сам, важно это для него или нет.

UPD 1 - кроме этого, одновременно с man-db.timer стартуют еще 2 таймера (то же ежедневно и тоже в 00:00) - logrotate.timer и shadow.timer, но они похоже много времени не тратят.

EDIT 1 - забыл отметить - лично я это не замечаю, так как в основном обновляюсь часто (1 раз в 1-2 дня) и этих секунд не замечаю.
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.