Зачем нужен man-db.service в Ubuntu
Обнаружил такой systemd сервис: man-db.service. Вызывается он раз в день с помощью таймера man-db.timer. Смотрю описание:
Подскажите пожалуйста, зачем такое может потребоваться?
Ну а вдруг вы установили что-то вне менеджера пакетов?
Systemd многое может, да, но не греть котлы в аду.
Каким боком тут systemd? Это убунтовские приколы. В Fedora такого нет.
Что там лежит поможет узнать Python:
Судя по всему, man-db.service нужен для генерации краткой справки по командам:
Спасибо за подробное исследование!
Получается я могу безболезненно этот таймер отключить и не думать о нем больше: при установке пакетов через dpkg будут вызваны триггеры для man-db которые перегенерируют все что надо один раз, а периодическая перегенерация — это пустая трата процессорного времени.
А разве в федоре man-db? Оно вроде только в Debian и производных.
так ставь арч. в гнем вообще по-дефолту ничего нет. я этот man-db.timer сто лет назад еще вручную ставил и включал
сто лет назад еще вручную ставил и включал
а зачем тебе потребовалась перегенерация man-db раз в день?
чтобы когда ты whatis вызываешь не ждать пока мановские файлы будут декодированы (они хранятся в формате gz) и распарсены, что бы в памяти построить какую-то структуру для удобной работы с ней.
Как видим эти файлы тоже имеют свой формат.
экономия процессороного времени в ущерб месту на диске
P.S. Вроде был баг с mandb где то год назад шуршал винтом минут 5 потом поправили. Проверте на pacnew /etc/cron.daily
—————————————————————————————————————————————————————–
Берем файл /usr/share/man/man5/modprobe.d.5.gz и распаковываем. Полученный текстовый файл modprobe.d.5 содержит единственную строку:
Заменяем ее на следующую:
и запаковываем обратно.
systemctl disable man-db.service
Интересно, за какое время у всех загружается по времени этот сервис?)
systemd-analyze blame | grep man-db
Systemd для продолжающих. Part 1 — Запуск юнитов по временным событиям
Всем привет! В последнее время я вплотную занимаюсь исследованием возможностей systemd и решил поделиться результатом исследований с сообществом, в виде небольшого (или большого, как пойдёт цикла статей. Итак первым (уже нет) номером нашей программы будет запуск юнитов по различным событиям происходящим во время работы ОС. В качестве исследовательской платформы будет выступать Manjaro Linux c systemd v247.2. И. да. Некоторые события, вынудили меня написать внеочередную статью, которая «взлетела на вершину хит-парада», а опрос показал, что тема актуальна и вызывает интерес, так что погнали!
Пролог
Systemd — система инициализации большинства современных систем на основе ядра Linux, обладает просто безграничными возможностями и не ограничивается обычным запуском демонов. Достаточно посмотреть на объёмы штатной документации, описывающей её возможности:
И это только маны описывающие конфиги, пользовательские и администраторские утилиты systemd. Если же не ограничивать поиск практической частью, то цифра будет ещё более «устрашающей»:
Большинство администраторов и разработчиков просто не представлют какие возможности таятся в недрах той системы, в окружении которых приходится работать их сервисам. Ну что-ж, пришлось время узнать, насколько глубока кроличья нора!
Disclamer: Хоть в официальной документации и манах почти не используется такое понятие как триггеры (хотя и используется «triggered by»), но все те штуки которые описаны в этой и следующей статье, по сути, именно ими и являются. Это сущности которые срабатывают по каким-либо событиям, поэтому не удивляйтесь, если я, авторским произволом, буду использовать этот термин.
Часть первая, очевидная. Таймеры.
Для начала… что запускаем. Возьмём, для примера, таймер man-db.timer из комплекта поставки одноимённого пакета:
Событийные таймеры
Таймеры привязанные к каким-либо событиям в системе.
OnBootSec= Таймер сработает через указанное время после старта системы.
OnStartupSec= Для системных таймеров действие аналогично предыдущему, для пользовательских таймеров, это время после первого логина пользователя в систему.
«Монотонные» таймеры
Периодически запускаемые таймеры.
OnUnitActiveSec= Триггер будет ориентироваться на время последнего запуска целевого юнита.
OnUnitInactiveSec= Триггер будет ориентироваться на последнее время завершения работы целевого юнита. Хорошо для долгоиграющих сервисов. Бэкапы и вот это вот всё.
Прочие параметры
FixedRandomDelay= Связанный с предыдущим параметром булевый параметр. Если включено, то при первом срабатывании таймера, джиттер запомнится (и для этого таймера станет постоянным), но запомнится хитро. Сама генерация рандома будет основана на имени пользователя, имени таймера, а самое главное MachineID, о котором будет рассказано в одной из следующих статей и который гарантированно разный, на разных хостах. Для чего это нужно? Например имеем сеть с кучей хостов, которые, например в начале рабочего дня, запускают таймеры, юниты которых ломятся на сервер, устраивая шторм запросов. Что-бы таймеры гарантированно срабатывали в разное время и следует использовать этот параметр.
Таймстампы, диапазоны, тестирование, примеры
Ну и наконец зачем это всё. Чем хороши таймеры, так это тем, что всяческие сложные временные метки задаются гораздо проще чем в cron и задача запуска сервиса раз в полтора часа, начиная с часа ночи, выглядит куда приятнее. В самом простом случае она будет выглядеть так:
Ну это слишком просто. Например мы хотим что-б наш юнит запускался каждую пятницу 13-е… OnCalendar=Fri *-*-13 12:00:00 Полный формат календарной формы выглядит так: Mon 2025-12-01 12:00:00.000000 Europe/Moscow Поэтому мы можем запускать таймер по времени другого часового пояса (по умолчанию текущий) Например хотим что-б таймер прислал нам уведомление, что Камчатка уже отпраздновала Новый год: OnCalendar=yearly Asia/Kamchatka Нормализованная форма будет выглядеть так (эти строчки указывают на одно и то-же время):
OnCalendar=*-01-01 00:00:00 Asia/Kamchatka Алиасы (и их эквиваленты в нормализованной форме) могут быть такими:
Примеры валидных таймстампов:
таймстамп с @ — epoch time
Перечисления и диапазоны:
Боольшой список примеров
Да. Микро и наносекунды тоже поддерживаются, а ещё очень удобная функция конца месяца и счётчик:
01 — Первый день с конца каждого месяца (он-же последний день месяца).
05 — 27-e мая каждого года (31-5).
07/1 — Последний понедельник декабря.
Mon *-12-01/3 — Третий понедельник декабря.
Проверять таймстампы на валидность можно при помощи утилиты systemd-analyze :
Вот так, в принципе, всё просто, логично и красиво. И разумеется напочитать:
Список статей серии
PS: Добавлена команда по выводу списка таймеров и плюсы-минусы таймеров, по сравнению с cron, в начале статьи. Спасибо @gecube!
PPS: Добавлены ссылки на ресурсы.
PPPS: Добавлено описание FixedRandomDelay= Довольно важный параметр о котором я успешно забыл.
Ресурсы
systemd.io — Статьи по внутренней кухне systemd. Частенько упоминается в манах.
systemd @ freedesktop.org — Основная страница с манами, документацией, видео, блогами и прочими ссылками на ресурсы.
@ru_systemd — Русскоязычный чат в Telegram. У нас тепло и лампово.
Долго запускается система из-за [email protected], man-db.service и большого лога systemd
Многие наблюдали как эти две службы тормозят загрузку системы:
До
Исправляем это.
Отключаем переодическое увеличение загрузки из-за man-db.service
Взято отсюда
Нужно создать два файла (если таких директорий нет, то тоже их создаём)
Создаём директории:
Сам файл, с содержимым:
[email protected] тормозит загрузку системы
Статья Wiki
Это происходит потому, что [email protected] ждёт получения ip-адреса, а потом запускается дальше. Исправим это поведение:
С таким содержимым:
2 Вариант решения борьбы с большим журналом Systemd
Просто выполним команду:
Эта команда ограничит размер журнала, удалив старую, не актуальную инфу.
После
P.S. В три раза быстрее (размер журнала у меня ограничен сразу после установки, зачастую он самый большой «ручник») 🙂
P.S.S такое ощущение, что системд это некая лохматая лапа а-ля MS, признанная включить ручник на Линуксах. надеюсь я не прав.
Запускаю руками mandb после обновлений.
С [email protected] на установленных арчах такой траблы у меня нет (сервис не запускается на старте), а вот при запуске в Live_Archiso присутствует.
—
В целом, спасибо за работу! У меня все руки не доходили. )
Ну этот то понятно, но вы зачем??
Там по умолчанию в timer стоит один раз в день. Шанс нарваться на это 30 сек. обновление составляет 1 к
2000, ну это если вы каждую секунду будет перезагружать компьютер, если просто будете работать в течении дня и перезагружать раз в день(а то и в месяц, год) шанс стремиться к нулю.
а dhcpcd я бы так делать не советовал, так как он специально не уходит в background дожидаясь получения ip и уже после этого нормального запуска сервисов в которых есть зависимость от этого.
НАЗВАНИЕ¶
ОПИСАНИЕ¶
В таблице ниже показаны номера справочных разделов и описание их содержимого.
| 1 | Исполняемые программы или команды оболочки (shell) |
| 2 | Системные вызовы (функции, предоставляемые ядром) |
| 3 | Библиотечные вызовы (функции, предоставляемые программными библиотеками) |
| 4 | Специальные файлы (обычно находящиеся в каталоге /dev) |
| 5 | Форматы файлов и соглашения, например о /etc/passwd |
| 6 | Игры |
| 7 | Разное (включает пакеты макросов и соглашения), например man(7), groff(7) |
| 8 | Команды администрирования системы (обычно, запускаемые только суперпользователем) |
| 9 | Процедуры ядра [нестандартный раздел] |
Справочная страница состоит из нескольких разделов.
Стандартные имена разделов: НАЗВАНИЕ (NAME), СИНТАКСИС (SYNOPSIS), НАСТРОЙКИ (CONFIGURATION), ОПИСАНИЕ (DESCRIPTION), ПАРАМЕТРЫ (OPTIONS), КОД ВЫХОДА (EXIT STATUS), ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ (RETURN VALUE), ОШИБКИ (ERRORS), ОКРУЖЕНИЕ (ENVIRONMENT), ФАЙЛЫ (FILES), ВЕРСИИ (VERSIONS), СОГЛАСУЕТСЯ С (CONFORMING TO), ЗАМЕЧАНИЯ (NOTES), ОШИБКИ (BUGS), ПРИМЕР (EXAMPLE), АВТОРЫ (AUTHORS) и СМОТРИТЕ ТАКЖЕ (SEE ALSO).
В разделе СИНТАКСИС используются следующие соглашения (которые также могут быть использованы в качестве основы для других разделов).
Точная отрисовка может отличаться на разных устройствах вывода. Например, man, обычно, не способна вывести курсив в терминале, и вместо него выведет текст подчёркнутым или цветным.
При объяснении команды или функции должен применяться шаблон, который точно описывает все возможные варианты вызова. В некоторых случаях рекомендуется показать несколько уникальных вызовов, как показано в разделе СИНТАКСИС этой справочной страницы.
ПРИМЕРЫ¶
ОБЗОР¶
Утилиты пейджера справочных страниц из пакета man-db широко используют кэши базы данных index. Эти кэши содержат информацию о расположении справочной страницы в файловой системе и какие данные whatis (короткое однострочное описание справочной страницы) она содержит, а также позволяют man работать быстрее, чем если бы каждый раз осуществлялся поиск по файловой системе для нахождения определённой справочной страницы. Если при запросе страницы указан параметр -u, то man проверит целостность кэшей, и в случае проблем может потребоваться ручной запуск программы по обновлению обычных текстовых баз данных whatis.
Если man не может найти mandb для первоначального создания базы данных index под определённую иерархию справочных страниц, то она попытается выполнить поиск запрашиваемых справочных страниц, хотя для этого потребуются универсальные имена файлов для поиска внутри иерархии. Если whatis или apropos не удастся найти index, то они попробуют извлечь информацию из традиционной текстовой базы данных whatis.
Утилиты пакета могут работать с сжатыми исходными файлами в формате nroff, имеющими расширения по умолчанию .Z, .z и .gz. Возможна работа с любыми расширениями, указывающими на сжатие, но эта информация задаётся на этапе компиляции. Также по умолчанию, любые создаваемые cat страницы сжимаются с помощью gzip. Каждой ‘глобальной’ иерархии справочных страниц, типа /usr/share/man или /usr/X11R6/man, может быть сопоставлен любой каталог для иерархии cat страниц. Обычно, cat страницы хранятся в той же иерархии что и справочные страницы, но по причинам, указанным в File Hierarchy Standard (FHS), может оказаться лучшим хранить их в другом месте. Подробней о том, как это сделать, читайте в manpath(5). Подробней о том, почему так делается, читайте стандарт.
Если запрашиваемая страница доступна для вашей локали, то она будет показана вместо стандартной (обычно, на американском английском) страницы.
Также в этом пакете есть переводы интерфейса на разные языки, которые могут быть включены тем же путём. Если вы обнаружили, что для вашего языка нет справочных страниц или не переведён интерфейс и вы хотите сделать это, то свяжитесь с сопровождающим, который скоординирует данную работу.
О других возможностях и расширениях, доступных в этом пейджере справочных страниц, читайте в описаниях из этого пакета.
ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ¶
После обнаружения справочной страницы выполняется проверка, существует ли уже отформатированный для неё `cat’ файл и что он новее, чем найденный nroff файл. Если уже отформатированный файл существует, он (обычно) расжимается и показывается с помощью пейджера. Нужную программу пейджер можно задать различными способами или используется значение по умолчанию (подробней смотрите в описании параметра -P). Если cat страница не найдена или старее, чем nroff файл, то nroff файл пропускается через различные программы и сразу же показывается.
Если есть возможность создать cat файл (существует соответствующий cat каталог и достаточно прав), то man сжимает и сохраняет cat файл в фоновом режиме.
где строка может содержать комбинацию букв, описанных в параметре -p ниже.
Если информация о фильтре нигде не указана, то используется набор по умолчанию.
Конвейер форматирования создаётся из фильтров и основной программы форматирования (nroff или [tg]roff с параметром -t) и выполняется. Или же, если существует исполняемая программа mandb_nfmt (или mandb_tfmt с параметром -t) в корне дерева справочных страниц, то выполняется именно она. Она получает файл с исходным текстом справочной страницы, строку препроцессора, и, необязательно, устройство, указанное в параметре -T или -E.
ПАРАМЕТРЫ¶
Общие параметры¶
Основные режимы работы¶
Поиск справочных страниц¶
Задаваемый в качестве manpath путь должен быть корнем иерархии справочных страниц, разделённой на разделы, описанных в справочной странице по man-db (в разделе «Система справочных страниц»). Для просмотра справочных страниц вне этих иерархий, используйте параметр -l.
Чтобы выключить такое поведение, укажите параметр —no-subpages.
Контролирование форматированного вывода¶
Значением может быть просто имя команды или команды с параметрами, можно использовать экранирование интерпретатора команд (обратные слэши, одиночные кавычки или двойные кавычки). Нельзя объединять несколько команд каналами; если эту нужно, создайте сценарий-обёртку, который получает файл для показа в виде параметра или со стандартного ввода.
-r приглашение, —prompt=приглашение Если в качестве пейджера используется новая версия less, то man будет пытаться установить ей формат приглашения и некоторые значимые параметры. По умолчанию приглашение выглядит как
Данное значение по умолчанию можно изменить с помощью параметра -r. Значение параметра может содержать текст $MAN_PN, вместо которого подставляется имя текущей справочной страницы и её название раздела, окружённое `(‘ и `)’. Строка, используемая для создания приглашения по умолчанию, могла бы выглядеть как
| Описание | Восьмеричный код | latin1 | ascii |
| длинный перенос | 255 | ‐ | — |
| bullet (точка в центре) | 267 | • | o |
| значок ударения | 264 | ´ | ‘ |
| знак ударения | 327 | × | x |
Если колонка latin1 отображается правильно, то ваш терминал может быть настроен для отображения символов latin1 и этот параметр ненужен. Если колонки latin1 и ascii одинаковы, то вы читаете эту страницу с помощью данного параметра, или man не отформатировал страницу с помощью описания устройства latin1. Если колонка latin1 отсутствует или повреждена, то вам может потребоваться просматривать справочные страницы с помощью этого параметра.
Этот параметр игнорируется при использовании параметров -t, -H, -T или -Z, и может быть бесполезен для nroff, если он не от GNU.
-E кодировка, —encoding=кодировка Сгенерировать вывод в символьной кодировке, отличной от используемой по умолчанию. Кроме реальной символьной кодировки, типа UTF-8, для обратной совместимости в кодировке можно указывать устройство nroff, например, ascii, latin1 или utf8. —no-hyphenation, —nh Обычно, nroff автоматически разбивает текст при окончании строки даже на словах, у которых нет переносов, если это необходимо для размещения слов в строке для избежания лишних пробелов. Этот параметр отключает автоматический перенос; в результате перенос выполняется только для слов, в которых есть символы переноса.
Если вы пишите справочную страницу и просто хотите отключить в nroff перенос в словах в неподходящем месте, не используйте этот параметр, а почитайте документацию к nroff; например, вы можете поместить «\%» внутрь слова в место возможного разрыва, или поместить «\%» в начало слова, что не даст его разорвать совсем.
—no-justification, —nj Обычно, nroff автоматически выравнивает текст по обеим границам. Этот параметр выключает полное выравнивание, оставляя выравнивание по левому краю, получается так называемый текст «без выключки по правому краю».
Если вы пишите справочную страницу и просто хотите отключить в nroff выравнивание в некоторых параграфах, не используйте этот параметр, а почитайте документацию к nroff; например, вы можете использовать запросы «.na», «.nf», «.fi», и «.ad» для временного отключения выравнивания и заполнения.
Выдача справки¶
КОД ВЫХОДА¶
ОКРУЖЕНИЕ¶
Значением может быть просто имя команды или команды с параметрами, можно использовать экранирование интерпретатора команд (обратные слэши, одиночные кавычки или двойные кавычки). Нельзя объединять несколько команд каналами; если эту нужно, создайте сценарий-обёртку, который получает файл для показа в виде параметра или со стандартного ввода.
ФАЙЛЫ¶
СМОТРИТЕ ТАКЖЕ¶
ИСТОРИЯ¶
23 декабря 1992: Рик Фейт (Rik Faith, faith@cs.unc.edu) исправил ошибки, найденные Виллемом Касдорпом (Willem Kasdorp, wkasdo@nikhefk.nikef.nl).
30 апреля 1994 – 23 февраля 2000: Вильф (Wilf., G.Wilford@ee.surrey.ac.uk) разрабатывал и сопровождал этот пакет с помощью некоторых других людей.
30 октября 1996 – 30 марта 2001: Фабрицио Полако (Fabrizio Polacco, сопровождал и улучшал этот пакет для проекта Debian с помощью всего сообщества.
31 марта 2001 – настоящие дни: Колин Уотсон (Colin Watson, занимается разработкой и сопровождением man-db.
