---
description: 'Эта глава объясняет большинство файлов конфигурации FreeBSD, как включить или отключить службу, как настроить систему ведения журналов и область управления питанием.'
next: books/handbook/boot
params:
  path: /books/handbook/config/
part: 'Часть III. Администрирование системы'
prev: books/handbook/partiii
showBookMenu: 'true'
tags: ["configuration", "services", "cron", "periodic", "logging", "configuration files", "sysctl", "swap", "power management"]
title: 'Глава 14. Конфигурация, сервисы, журналирование и управление питанием'
weight: 18
---

[[config-tuning]]
= Конфигурация, сервисы, журналирование и управление питанием
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 14
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/config/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[config-synopsis]]
== Обзор

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

Прежде чем читать эту главу, необходимо:

* Понимать основы UNIX(R) и FreeBSD (crossref:basics[basics,Основы FreeBSD]).

Прочтите эту главу, чтобы узнать:

* Как использовать различные конфигурационные файлы в [.filename]#/etc#.
* Основы настройки [.filename]#rc.conf# и скриптов запуска в [.filename]#/usr/local/etc/rc.d#.
* Как настроить FreeBSD с помощью переменных man:sysctl[8].
* Как настроить управление питанием в FreeBSD.

[[configtuning-configfiles]]
== Файлы конфигурации

FreeBSD поддерживает четкое разделение между базовой системой и сторонними приложениями, что влияет на расположение их конфигурационных файлов.

Конфигурация базовой системы FreeBSD находится в каталоге [.filename]#/etc#, а в каталоге [.filename]#/usr/local/etc# содержатся все конфигурационные файлы приложений, установленных в систему через коллекцию портов и пакеты.

Конфигурация состояния ядра находится в файле [.filename]#/etc/sysctl.conf#. В разделе crossref:config[configtuning-sysctl, Утилита sysctl] работа man:sysctl[8] будет рассмотрена более подробно.

Для получения дополнительной информации о структуре файловой системы FreeBSD обратитесь к man:hier[7].

Как правило, конфигурационные файлы не придерживаются единого стандарта в отношении синтаксиса. Хотя верно, что символ `#` обычно используется для комментирования строки и что каждая строка содержит переменную конфигурации.

[NOTE]
====
Некоторые приложения, такие как man:pkg[8], начинают использовать link:https://github.com/vstakhov/libucl[Universal Configuration Language (UCL)].
====

=== Каталог [.filename]#/etc#

Каталог [.filename]#/etc# содержит все файлы конфигурации базовой системы FreeBSD, которые отвечают за её настройку.

[CAUTION]
====
*Крайнюю* осторожность следует соблюдать при изменении файлов в каталоге [.filename]#/etc#; неправильная настройка может сделать FreeBSD незагружаемой или неработоспособной.
====

[.informaltable]
[cols="1,1", frame="none"]
|===

|[.filename]#/etc#
|Системные конфигурационные файлы и скрипты.

|[.filename]#/etc/defaults#
|Файлы конфигурации системы по умолчанию, подробности см. в man:rc[8].

|[.filename]#/etc/fstab#
|man:fstab[5] содержит описательную информацию о различных файловых системах.

|[.filename]#/etc/mail#
|Дополнительная конфигурация man:sendmail[8] и другие файлы конфигурации MTA.

|[.filename]#/etc/mtree#
|Файлы конфигурации mtree, подробнее см. man:mtree[8].

|[.filename]#/etc/pam.d#
|Файлы конфигурации библиотеки Pluggable Authentication Modules (PAM).

|[.filename]#/etc/periodic#
|Скрипты, выполняемые ежедневно, еженедельно и ежемесячно через man:cron[8]. Подробнее см. man:periodic[8].

|[.filename]#/etc/rc.d#
|Системные и демон-скрипты запуска/управления, подробнее см. в man:rc[8].

|[.filename]#/etc/rc.conf#
|Содержит описательную информацию о локальном имени хоста,
настройках сетевых интерфейсов и службах, которые должны
запускаться при начальной загрузке системы. Подробнее в разделе
 crossref:bsdinstall[configtuning-core-configuration, Управление системными настройками]

|[.filename]#/etc/security#
|Файлы конфигурации аудита OpenBSM, дополнительную информацию смотрите в man:audit[8].

|[.filename]#/etc/ppp#
|Файлы конфигурации ppp, подробности смотрите в man:ppp[8].

|[.filename]#/etc/ssh#
|Файлы конфигурации OpenSSH, подробности см. в man:ssh[1].

|[.filename]#/etc/ssl#
|Конфигурационные файлы OpenSSL.

|[.filename]#/etc/sysctl.conf#
|Содержит настройки ядра. Дополнительная информация в
crossref:bsdinstall[configtuning-sysctl, Утилита sysctl]

|===

[[configtuning-sysctl]]
=== Утилита sysctl

Утилита man:sysctl[8] используется для внесения изменений в работающую систему FreeBSD.

Утилита man:sysctl[8] позволяет получать состояние ядра и, при наличии соответствующих привилегий, изменять его. Состояние, которое требуется получить или установить, описывается с использованием имени в стиле "Базы управляющей информации" ("MIB"), представленного в виде набора компонентов, разделённых точками.

.База управляющей информации
[.informaltable]
[cols="1,1", frame="none"]
|===

|sysctl
|«Волшебные» числа

|kern
|Ядро: функции и возможности

|vm
|Виртуальная память

|vfs
|Файловая система

|net
|Сеть

|debug
|Параметры отладки

|hw
|Оборудование

|machdep
|Зависимые от аппаратного обеспечения

|user
|Пользовательское пространство

|p1003_1b
|POSIX 1003.1B

|===

В основе своей man:sysctl[8] выполняет две функции: чтение и изменение системных настроек.

Для просмотра всех доступных для чтения переменных:

[source, shell]
....
% sysctl -a
....

Вывод должен быть похож на следующий:

[.programlisting]
....
kern.ostype: FreeBSD
...
vm.swap_enabled: 1
vm.overcommit: 0
vm.domain.0.pidctrl.kdd: 8
vm.domain.0.pidctrl.kid: 4
vm.domain.0.pidctrl.kpd: 3
...
vfs.zfs.sync_pass_rewrite: 2
vfs.zfs.sync_pass_dont_compress: 8
vfs.zfs.sync_pass_deferred_free: 2
....

Чтобы прочитать конкретную переменную, укажите её имя:

[source, shell]
....
% sysctl kern.maxproc
....

Вывод должен быть похож на следующий:

[.programlisting]
....
kern.maxproc: 1044
....

База управляющей информации (MIB) иерархична, поэтому указание префикса выводит все узлы, зависящие от него:

[source, shell]
....
% sysctl net
....

Вывод должен быть похож на следующий:

[.programlisting]
....
net.local.stream.recvspace: 8192
net.local.stream.sendspace: 8192
net.local.dgram.recvspace: 16384
net.local.dgram.maxdgram: 2048
net.local.seqpacket.recvspace: 8192
net.local.seqpacket.maxseqpacket: 8192
net.local.sockcount: 60
net.local.taskcount: 25
net.local.recycled: 0
net.local.deferred: 0
net.local.inflight: 0
net.inet.ip.portrange.randomtime: 1
net.inet.ip.portrange.randomcps: 9999
[...]
....

Чтобы установить конкретную переменную, используйте синтаксис _переменная_=_значение_:

[source, shell]
....
# sysctl kern.maxfiles=5000
....

Вывод должен быть похож на следующий:

[.programlisting]
....
kern.maxfiles: 2088 -> 5000
....

[NOTE]
====
Чтобы сохранить настройки после перезагрузки, необходимо добавить эти переменные в файл [.filename]#/etc/sysctl.conf#, как описано ниже.
====

[[configtuning-sysctlconf]]
=== Файл [.filename]#/etc/sysctl.conf#

Файл конфигурации для man:sysctl[8], [.filename]#/etc/sysctl.conf#, выглядит очень похоже на [.filename]#/etc/rc.conf#.

Значения задаются с использованием синтаксиса `переменная=значение`.

[NOTE]
====
Указанные значения устанавливаются после перехода системы в многопользовательский режим. Не все переменные могут быть установлены в этом режиме.
====

Например, чтобы отключить запись завершений по фатальным сигналам и запретить пользователям видеть процессы, запущенные другими пользователями, в файле [.filename]#/etc/sysctl.conf# можно установить следующие параметры:

[.programlisting]
....
# Do not log fatal signal exits (e.g., sig 11)
kern.logsigexit=0

# Prevent users from seeing information about processes that
# are being run under another UID.
security.bsd.see_other_uids=0
....

Чтобы получить дополнительную информацию о функции конкретного sysctl, можно выполнить следующую команду:

[source, shell]
....
% sysctl -d kern.dfldsiz
....

Вывод должен быть похож на следующий:

[.programlisting]
....
kern.dfldsiz: Initial data size limit
....

[[configtuning-core-configuration]]
=== Управление конфигурацией, специфичной для системы

Основное расположение информации о конфигурации системы — это [.filename]#/etc/rc.conf#.

Этот файл содержит обширную информацию о конфигурации и читается при запуске системы для её настройки. Он предоставляет конфигурационную информацию для файлов [.filename]#rc*#.

Записи в [.filename]#/etc/rc.conf# переопределяют настройки по умолчанию из [.filename]#/etc/defaults/rc.conf#.

[TIP]
====
Файл [.filename]#/etc/defaults/rc.conf#, содержащий настройки по умолчанию, не следует редактировать. Вместо этого все специфичные для системы изменения должны вноситься в [.filename]#/etc/rc.conf#.
====

В кластеризованных приложениях может быть применен ряд стратегий для разделения общесайтовой конфигурации и системно-специфичной конфигурации с целью снижения административной нагрузки.

Рекомендуемый подход заключается в размещении специфичной для системы конфигурации в [.filename]#/etc/rc.conf.local#.

Например, эти записи в [.filename]#/etc/rc.conf# применяются ко всем системам:

[.programlisting]
....
sshd_enable="YES"
keyrate="fast"
defaultrouter="10.1.1.254"
....

В то время как эти записи в [.filename]#/etc/rc.conf.local# применяются только к этой системе:

[.programlisting]
....
hostname="node1.example.org"
ifconfig_fxp0="inet 10.1.1.1/8"
....

Распределите [.filename]#/etc/rc.conf# на каждую систему с помощью таких приложений, как rsync или puppet, в то время как [.filename]#/etc/rc.conf.local# остаётся уникальным.

Обновление системы не перезапишет [.filename]#/etc/rc.conf#, поэтому системные настройки не будут потеряны.

[TIP]
====
Оба файла [.filename]#/etc/rc.conf# и [.filename]#/etc/rc.conf.local# обрабатываются man:sh[1]. Это позволяет системным операторам создавать сложные сценарии конфигурации. Дополнительную информацию по этой теме можно найти в man:rc.conf[5].
====

[[configtuning-rcd]]
== Управление службами в FreeBSD

FreeBSD использует систему стартовых сценариев man:rc[8] для инициализации системы и управления службами.

Скрипты, перечисленные в [.filename]#/etc/rc.d#, предоставляют базовые сервисы, которыми можно управлять с помощью опций `start`, `stop` и `restart` команды man:service[8].

Базовый скрипт может выглядеть следующим образом:

[.programlisting]
....
#!/bin/sh
#
# PROVIDE: utility
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name=utility
rcvar=utility_enable

command="/usr/local/sbin/utility"

load_rc_config $name

#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
# SET THEM IN THE /etc/rc.conf FILE
#
utility_enable=${utility_enable-"NO"}
pidfile=${utility_pidfile-"/var/run/utility.pid"}

run_rc_command "$1"
....

Обратитесь к extref:{rc-scripting}[этой статье] для получения инструкций по созданию пользовательских сценариев man:rc[8].

[[configtuning-starting-services]]
=== Запуск служб

Многие пользователи устанавливают стороннее программное обеспечение на FreeBSD из Коллекции портов и требуют, чтобы установленные службы запускались при инициализации системы.

Службы, такие как package:security/openssh-portable[] или package:www/nginx[], являются лишь двумя из множества программных пакетов, которые могут запускаться при инициализации системы. В этом разделе описаны доступные процедуры для запуска служб.

Поскольку система man:rc[8] в первую очередь предназначена для запуска и остановки служб во время загрузки и выключения системы, опции `start`, `stop` и `restart` выполнят соответствующие действия только в том случае, если установлена соответствующая переменная в [.filename]#/etc/rc.conf#.

Итак, первый шаг для запуска службы, например package:www/nginx[], — это добавить её в [.filename]#/etc/rc.conf#, выполнив следующую команду:

[source, shell]
....
# sysrc nginx_enable="YES"
....

Затем nginx можно запустить, выполнив следующую команду:

[source, shell]
....
# service nginx start
....

[TIP]
====
Для запуска (`start`), остановки (`stop`) или перезапуска (`restart`) службы независимо от настроек в [.filename]#/etc/rc.conf#, перед этими командами следует добавить "one". Например, чтобы запустить package:www/nginx[] независимо от текущих настроек в [.filename]#/etc/rc.conf#, выполните следующую команду:

[source, shell]
....
# service nginx onestart
....
====

Также возможно автоматическое размещение службы в jail, см. соответствующее пояснение в разделе crossref:jails[service-jails,Сервисные клетки].

[[configtuning-status-services]]
=== Состояние службы

Чтобы определить, запущена ли служба, используйте подкоманду `status`.

Например, чтобы проверить, что package:www/nginx[] работает:

[source, shell]
....
# service nginx status
....

Вывод должен быть похож на следующий:

[.programlisting]
....
nginx is running as pid 27871.
....

[[configtuning-reload-services]]
=== Перезагрузить службу

В некоторых случаях также можно `перезагрузить` службу. Это попытка отправить сигнал отдельной службе, заставляя её перезагрузить свои конфигурационные файлы.

В большинстве случаев это означает отправку службе сигнала `SIGHUP`.

*Не все службы поддерживают эту возможность.*

Система man:rc[8] используется для сетевых сервисов, а также играет важную роль в большинстве процессов инициализации системы. Например, при выполнении скрипта [.filename]#/etc/rc.d/bgfsck# выводится следующее сообщение:

[source, shell]
....
Starting background file system checks in 60 seconds.
....

Этот скрипт используется для фоновой проверки файловых систем, которая выполняется только во время инициализации системы.

Многие системные службы зависят от других служб для корректной работы. Например, man:yp[8] и другие службы на основе RPC могут не запуститься, пока не будет запущена служба man:rpcbind[8].

Дополнительную информацию можно найти в man:rc[8] и man:rc.subr[8].

=== Использование служб для запуска сервисов

Другие службы могут быть запущены с помощью man:inetd[8]. Работа с man:inetd[8] и его настройка подробно описаны в crossref:network-servers[network-inetd,«Суперсервер inetd»].

В некоторых случаях может быть целесообразнее использовать man:cron[8] для запуска системных служб. Такой подход имеет ряд преимуществ, поскольку man:cron[8] запускает эти процессы от имени владельца man:crontab[5]. Это позволяет обычным пользователям запускать и поддерживать свои собственные приложения.

Функция `@reboot` в man:cron[8] может быть использована вместо указания времени. Это приводит к запуску задачи при старте man:cron[8], обычно во время инициализации системы.

[[cron-periodic]]
== Cron и Periodic

Планирование задач на определённый день или время — очень распространённая задача в FreeBSD. Инструмент, отвечающий за выполнение этой задачи, — это man:cron[8].

В дополнение к задачам, которые пользователь может запланировать с помощью man:cron[8], FreeBSD выполняет фоновые задачи, управляемые man:periodic[8].

[[configtuning-cron]]
=== Cron

Утилита man:cron[8] работает в фоновом режиме и периодически проверяет файл [.filename]#/etc/crontab# на наличие задач для выполнения, а также ищет пользовательские файлы crontab в каталоге [.filename]#/var/cron/tabs#.

Эти файлы используются для планирования задач, которые cron запускает в указанное время.

Каждая запись в crontab определяет задачу для выполнения и называется _cron job_.

Используются два типа конфигурационных файлов: системный crontab, который не следует изменять, и пользовательские crontabs, которые можно создавать и редактировать по необходимости. Формат этих файлов описан в man:crontab[5]. Формат системного crontab, [.filename]#/etc/crontab#, включает столбец `who`, который отсутствует в пользовательских crontabs. В системном crontab команды выполняются от имени пользователя, указанного в этом столбце. В пользовательском crontab все команды выполняются от имени пользователя, создавшего crontab.

Пользовательские crontab-файлы позволяют отдельным пользователям планировать свои собственные задачи. У пользователя `root` также может быть пользовательский [.filename]#crontab#, который можно использовать для планирования задач, отсутствующих в системном [.filename]#crontab#.

Вот пример записи из системного crontab, [.filename]#/etc/crontab#:

[.programlisting]
....
# /etc/crontab - root's crontab for FreeBSD
#
# <.>
#
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin <.>
#
#minute hour    mday    month   wday    who     command <.>
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11    *       *       *       *       operator /usr/libexec/save-entropy <.>
#
# Rotate log files every hour, if necessary.
0       *       *       *       *       root    newsyslog
#
# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31    0-5     *       *       *       root    adjkerntz -a

....

<.> Строки, начинающиеся с символа `+#+`, являются комментариями. Комментарий можно добавить в файл как напоминание о том, что и зачем выполняется. Комментарии не могут находиться на одной строке с командой, иначе они будут восприняты как часть команды; они должны быть на отдельной строке. Пустые строки игнорируются.

<.> Символ равенства (`=`) используется для определения параметров окружения. В данном примере он применяется для задания переменных `SHELL` и `PATH`. Если `SHELL` не указана, cron будет использовать оболочку Bourne по умолчанию. Если `PATH` не указан, необходимо указывать полный путь к команде или скрипту, который требуется выполнить.

<.> Эта строка определяет семь полей, используемых в системном crontab: `minute`, `hour`, `mday`, `month`, `wday`, `who` и `command`. Поле `minute` указывает время в минутах, когда должна выполняться указанная команда, `hour` — час, `mday` — день месяца, `month` — месяц, а `wday` — день недели. Эти поля должны содержать числовые значения в 24-часовом формате или символ `*`, обозначающий все возможные значения для данного поля. Поле `who` существует только в системном crontab и указывает, от имени какого пользователя должна выполняться команда. Последнее поле — это команда, которую нужно выполнить.

<.> Эта запись определяет значения для этого задания cron. Комбинация `\*/11`, за которой следует несколько символов `*`, указывает, что `/usr/libexec/save-entropy` запускается от имени пользователя `operator` каждые одиннадцать минут каждого часа, каждого дня и дня недели, каждого месяца. Команды могут включать любое количество параметров. Однако команды, занимающие несколько строк, должны быть разделены символом продолжения обратной косой черты "\".

[[configtuning-installcrontab]]
=== Создание пользовательского Crontab

Чтобы создать пользовательский crontab, вызовите `crontab` в режиме редактора:

[source, shell]
....
% crontab -e
....

Это откроет crontab пользователя в текстовом редакторе по умолчанию. При первом запуске этой команды откроется пустой файл. После создания crontab эта команда будет открывать его для редактирования.

Полезно добавить следующие строки в начало файла crontab, чтобы установить переменные окружения и запомнить назначение полей в crontab:

[.programlisting]
....
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
# Order of crontab fields
# minute hour mday month wday command
....

Затем добавьте строку для каждой команды или скрипта, указав время их выполнения. В этом примере указанный пользовательский скрипт Bourne shell будет запускаться каждый день в два часа дня. Поскольку путь к скрипту не указан в `PATH`, указывается полный путь к скрипту:

[.programlisting]
....
0 14 * * * /home/user/bin/mycustomscript.sh
....

[TIP]
====
Перед использованием пользовательского скрипта убедитесь, что он исполняемый, и протестируйте его с ограниченным набором переменных окружения, установленных cron. Чтобы воспроизвести окружение, которое будет использоваться для выполнения вышеуказанной записи cron, используйте:

[.programlisting]
....
env -i SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/home/user LOGNAME=user /home/user/bin/mycustomscript.sh
....

Окружение, устанавливаемое cron, описано в man:crontab[5]. Особенно важно проверять корректность работы скриптов в окружении cron, если они содержат команды удаления файлов с использованием шаблонов.
====

После завершения редактирования файла crontab сохраните его. Он будет автоматически установлен, и cron прочитает crontab и запустит задания по расписанию. Для просмотра списка заданий в crontab используйте следующую команду:

[source, shell]
....
% crontab -l
....

Вывод должен быть похож на следующий:

[.programlisting]
....
0 14 * * * /home/user/bin/mycustomscript.sh
....

Удалить все задания cron из пользовательского crontab:

[source, shell]
....
% crontab -r
....

Вывод должен быть похож на следующий:

[.programlisting]
....
remove crontab for user? y
....

[[configtuning-periodic]]
=== Периодические задачи (Periodic)

FreeBSD предоставляет набор скриптов для управления системой, которые проверяют состояние различных подсистем, выполняют проверки, связанные с безопасностью, осуществляют ротацию файлов журналов и т.д. Эти скрипты запускаются периодически: ежедневно, еженедельно или ежемесячно. Управление этими задачами осуществляется с помощью man:periodic[8], а его конфигурация находится в man:periodic.conf[5]. Периодические задачи инициируются записями в системном crontab, как показано выше.

Скрипты, выполняемые man:periodic[8], расположены в [.filename]#/etc/periodic/# для базовых утилит и в [.filename]#/usr/local/etc/periodic/# для стороннего программного обеспечения.

Они организованы в 4 подкаталога: daily, weekly, monthly и security.

[[enable-disable-periodic]]
=== Включение или отключение периодических задач

FreeBSD имеет некоторые скрипты, включённые по умолчанию для периодического выполнения.

Чтобы включить или отключить задачу, первым шагом необходимо отредактировать файл [.filename]#/etc/periodic.conf#, выполнив следующую команду:

[source, shell]
....
# ee /etc/periodic.conf
....

И затем, чтобы включить, например, `daily_status_zfs_enable`, поместите следующее содержимое в файл:

[.programlisting]
....
daily_status_zfs_enable="YES"
....

Чтобы отключить задание, которое активно по умолчанию, достаточно изменить `YES` на `NO`.

[[configuring-output-periodic-tasks]]
=== Настройка вывода периодических задач

В файле [.filename]#/etc/periodic.conf# переменные `daily_output`, `weekly_output` и `monthly_output` определяют, куда отправлять результаты выполнения скриптов.

По умолчанию результаты работы периодических скриптов отправляются по электронной почте пользователю root, поэтому рекомендуется либо читать почту root, либо настроить пересылку писем root на почтовый ящик, который регулярно проверяется.

Чтобы отправить результаты на другой адрес электронной почты или на несколько адресов, добавьте email-адреса через пробел в файл [.filename]#/etc/periodic.conf#:

[.programlisting]
....
daily_output="email1@example.com email2@example.com"
weekly_output="email1@example.com email2@example.com"
monthly_output="email1@example.com email2@example.com"
....

Для записи периодического вывода в журнал вместо получения его по электронной почте добавьте следующие строки в [.filename]#/etc/periodic.conf#. Утилита man:newsyslog[8] будет выполнять ротацию этих файлов в соответствующее время:

[.programlisting]
....
daily_output=/var/log/daily.log
weekly_output=/var/log/weekly.log
monthly_output=/var/log/monthly.log
....

[[configtuning-syslog]]
== Настройка системного журналирования

Генерация и чтение системных журналов — важный аспект администрирования системы. Информация в системных журналах может использоваться для выявления проблем с оборудованием и программным обеспечением, а также ошибок в конфигурации приложений и системы. Эти данные также играют важную роль в аудите безопасности и реагировании на инциденты. Большинство системных демонов и приложений создают записи в журналах.

FreeBSD предоставляет системный модуль журналирования man:syslogd[8] для управления журналированием. По умолчанию syslogd включен и запускается при загрузке системы.

В этом разделе описывается, как настроить системный модуль журналирования FreeBSD для локального и удалённого ведения журналов, а также как выполнять ротацию и управление журналами.

=== Настройка локального журналирования

Файл конфигурации [.filename]#/etc/syslog.conf# определяет, как syslogd обрабатывает поступающие записи журналов. Существует несколько параметров для управления обработкой входящих событий. _Facility_ (источник) указывает, какая подсистема сгенерировала сообщение, например, ядро или демон, а _level_ (уровень) описывает степень серьезности произошедшего события. Это позволяет настроить, будет ли сообщение зарегистрировано и куда, в зависимости от категории и уровня. Также можно выполнять действия в зависимости от приложения, отправившего сообщение, а в случае удалённого журналирования — от имени хоста машины, генерирующей событие.

Этот файл конфигурации содержит по одной строке для каждого действия, где синтаксис каждой строки представляет собой поле селектора, за которым следует поле действия. Синтаксис поля селектора — _facility.level_, что соответствует журнальным сообщениям от _facility_ уровня _level_ и выше. Также можно добавить необязательный флаг сравнения перед уровнем, чтобы точнее указать, что регистрируется. Для одного действия можно использовать несколько полей селектора, разделённых точкой с запятой (`;`). Использование `*` соответствует всем сообщениям. Поле действия указывает, куда отправлять журнальное сообщение, например, в файл или на удалённый хост для журналирования.

В качестве примера приведен стандартный файл [.filename]#/etc/syslog.conf# из FreeBSD:

[.programlisting]
....
#       Spaces ARE valid field separators in this file. However,
#       other *nix-like systems still insist on using tabs as field
#       separators. If you are sharing this file between systems, you
#       may want to use only tabs as field separators here.
#       Consult the syslog.conf(5) manpage.
*.err;kern.warning;auth.notice;mail.crit                /dev/console <.>
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
security.*                                      /var/log/security
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog <.>
cron.*                                          /var/log/cron
!-devd
*.=debug                                        /var/log/debug.log <.>
*.emerg                                         *
daemon.info                                     /var/log/daemon.log
# uncomment this to log all writes to /dev/console to /var/log/console.log
# touch /var/log/console.log and chmod it to mode 600 before it will work
#console.info                                   /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
# touch /var/log/all.log and chmod it to mode 600 before it will work
#*.*                                            /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.*                                            @loghost
# uncomment these if you're running inn
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
# Uncomment this if you wish to see messages produced by devd
# !devd
# *.>=notice                                    /var/log/devd.log <.>
!*
include                                         /etc/syslog.d
include                                         /usr/local/etc/syslog.d
....

<.> Соответствует всем сообщениям с уровнем `err` или выше, а также `kern.warning`, `auth.notice` и `mail.crit`, и отправляет эти сообщения журнала на консоль ([.filename]#/dev/console#).
<.> Соответствует всем сообщениям из источника `mail` уровня `info` и выше и записывает их в [.filename]#/var/log/maillog#.
<.> Использует флаг сравнения (`=`) для совпадения только с сообщениями уровня `debug` и записывает их в [.filename]#/var/log/debug.log#.
<.> Пример использования спецификации программы. Это делает следующие правила действительными только для указанной программы. В данном случае только сообщения, генерируемые man:devd[8], записываются в [.filename]#/var/log/devd.log#.

Для получения дополнительной информации о [.filename]#/etc/syslog.conf#, его синтаксисе и более сложных примерах использования см. man:syslog.conf[5].

[[logging-facilities]]
=== Источники системы журналирования

Источник описывает часть системы, генерирующую сообщение. Источники — это способ разделения различных сообщений, чтобы пользователю было проще анализировать журналы.

.Источники системных журналов (syslog)
[options="header", cols="1,1"]
|===
| Имя | Описание

| auth
| Система авторизации: man:login[1], man:su[1], man:getty[8] и т.д.

| authpriv
| То же, что и auth, но записывается в файл, доступный только для чтения root.

| console
| Сообщения, записываемые драйвером вывода консоли ядра в [.filename]#/dev/console#.

| cron
| Сообщения, записываемые демоном man:cron[8].

| daemon
| Системные демоны, такие как man:routed[8], которые не предусмотрены явно другими средствами.

| ftp
| Демоны протокола передачи файлов: man:ftpd[8], man:tftpd[8].

| kern
| Сообщения, генерируемые ядром. Они не могут быть созданы какими-либо пользовательскими процессами.

| lpr
| Система буферизации принтеров: man:lpr[1], man:lpc[8], man:lpd[8] и т.д.

| mail
| Почтовая система.

| mark
| Этот механизм добавляет запись каждые 20 минут.

| news
| Система сетевых новостей.

| ntp
| Система протокола сетевого времени.

| security
| Подсистемы безопасности, такие как man:ipfw[4].

| syslog
| Сообщения, генерируемые внутренне syslogd(8).

| user
| Сообщения, генерируемые случайными пользовательскими процессами. *Это идентификатор источника по умолчанию, если не указан другой*.

| uucp
| Система Unix-to-Unix Copy. Устаревший протокол. Очень странно видеть сообщения от этого сервиса.

| от `local0`до `local7`
| Зарезервировано для локального использования.

|===

[[logging-levels]]
=== Уровни журналирования

Уровень описывает степень важности сообщения и является ключевым словом из следующего упорядоченного списка (от высшего к низшему):

.Уровни в syslog
[options="header", cols="1,1"]
|===
| Имя | Описание

| emerg
| Паника. Обычно это сообщение рассылается всем пользователям.

| alert
| Условие, которое должно быть немедленно исправлено, например, повреждение системной базы данных.

| crit
| Критические условия, например, аппаратные ошибки устройств.

| err
| Ошибки.

| warning
| Предупреждающие сообщения.

| notice
| Условия, которые не являются ошибочными, но, возможно, требуют специальной обработки.

| info
| Информационные сообщения.

| debug
| Сообщения, содержащие информацию, которая обычно полезна только при отладке программы.

| none
| Этот специальный уровень отключает определённую функцию.

|===

[[read-log-messages]]
=== Как читать сообщения журналов

По умолчанию журнальные файлы FreeBSD используют формат link:https://datatracker.ietf.org/doc/html/rfc3164[rfc3164], также известный как протокол BSD syslog. Подробнее о других форматах и их использовании можно узнать в man:syslog[8].

Обычно журналы имеют следующий синтаксис:

[.programlisting]
....
date time hostname program[pid]: the message
....

В качестве примера будет использоваться вывод файла [.filename]#/var/log/cron#:

[.programlisting]
....
[...]
Jul 16 12:40:00 FreeBSD /usr/sbin/cron[81519]: (root) CMD (/usr/libexec/atrun)
Jul 16 12:44:00 FreeBSD /usr/sbin/cron[83072]: (operator) CMD (/usr/libexec/save-entropy)
[...]
....

Подробное журналирование, при котором к каждому сообщению добавляются данные о facility и level, можно включить в man:syslog[8], выполнив следующую команду:

[source, shell]
....
# sysrc syslogd_flags="-vv"
....

После активации функции источник и уровень будут отображаться в журнале, как показано в следующем примере:

[.programlisting]
....
[...]
Jul 16 17:40:00 <cron.info> FreeBSD /usr/sbin/cron[1016]: (root) CMD (/usr/libexec/atrun)
Jul 16 17:44:00 <cron.info> FreeBSD /usr/sbin/cron[1030]: (operator) CMD (/usr/libexec/save-entropy)
[...]
....

=== Управление журналами и их ротация

Файлы журналов могут быстро увеличиваться в размере, занимая место на диске и затрудняя поиск полезной информации.

В FreeBSD для управления файлами журналов и предотвращения этой проблемы используется man:newsyslog[8].

Эта встроенная программа периодически выполняет ротацию и сжатие файлов журналов, а также при необходимости создает отсутствующие файлы журналов и отправляет сигналы программам при перемещении файлов журналов.

[NOTE]
====
Поскольку newsyslog запускается через man:cron[8], он не может выполнять ротацию файлов чаще, чем запланировано в man:cron[8]. В стандартной конфигурации он запускается каждый час.
====

Вот стандартная конфигурация в FreeBSD, подробнее можно узнать в man:newsyslog.conf[5]:

[.programlisting]
....
# configuration file for newsyslog
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/all.log                        600  7     *    @T00  J
/var/log/auth.log                       600  7     1000 @0101T JC
/var/log/console.log                    600  5     1000 *     J
/var/log/cron                           600  3     1000 *     JC
/var/log/daily.log                      640  7     *    @T00  JN
/var/log/debug.log                      600  7     1000 *     JC
/var/log/init.log                       644  3     1000 *     J
/var/log/kerberos.log                   600  7     1000 *     J
/var/log/maillog                        640  7     *    @T00  JC
/var/log/messages                       644  5     1000 @0101T JC
/var/log/monthly.log                    640  12    *    $M1D0 JN
/var/log/devd.log                       644  3     1000 *     JC
/var/log/security                       600  10    1000 *     JC
/var/log/utx.log                        644  3     *    @01T05 B
/var/log/weekly.log                     640  5     *    $W6D0 JN
/var/log/daemon.log                     644  5     1000 @0101T JC

<include> /etc/newsyslog.conf.d/[!.]*.conf
<include> /usr/local/etc/newsyslog.conf.d/[!.]*.conf
....

. `logfilename` - Имя файла системного журнала, предназначенного для архивирования.
. `[owner:group]` - Это необязательное поле указывает владельца и группу для архивируемого файла.
. `mode` - Указывает режим доступа к файлу журнала и архивам. Допустимые биты режима - 0666. (То есть, права на чтение и запись для ротированного журнала могут быть заданы для владельца, группы и остальных пользователей.)
. `count` - Указывает максимальное количество архивных файлов, которые могут существовать.
. `size` — Когда размер файла журнала достигает указанного размера в килобайтах, файл журнала будет обрезан, как описано выше. Если в этом поле указана звёздочка ('*'), файл журнала не будет обрезаться по размеру.
. `when` - Может состоять из интервала, конкретного времени или обоих вариантов. Поддерживаемые опции описаны в man:newsyslog.conf[5].
. `flags` - Указывает флаги, которые принимает newsyslog, поддерживаемые опции описаны в man:newsyslog.conf[5].
. `[/pid_file]` - Это необязательное поле указывает имя файла, содержащего идентификатор процесса (PID) демона или идентификатор группы процессов.
. `[sig_num]` - Это необязательное поле указывает сигнал, который будет отправлен процессу демона.

[NOTE]
====
Последние два поля необязательны и указывают имя файла ID процесса (PID) и номер сигнала, который будет отправлен этому процессу при ротации файла.
====

[[network-syslogd]]
=== Настройка удаленного журналирования

Мониторинг журналов событий на нескольких хостах может стать громоздким по мере увеличения количества систем. Настройка централизованного журналирования позволяет снизить нагрузку на администратора при управлении журналами.

В FreeBSD централизованная агрегация, объединение и ротация файлов журналов могут быть настроены с помощью `syslogd` и `newsyslog`.

В этом разделе приведен пример конфигурации, в которой хост `A` с именем `logserv.example.com` будет собирать информацию журналирования для локальной сети.

Узел `B` с именем `logclient.example.com` будет настроен для передачи информации журналирования на сервер журналирования.

==== Конфигурация сервера журналов

Сервер журналов — это система, настроенная для приёма информации журналирования с других узлов.

Перед настройкой сервера журналов проверьте следующее:

* Если между сервером журналирования и клиентами журналирования есть межсетевой экран, убедитесь, что набор правил межсетевого экрана разрешает UDP-порт 514 как для клиентов, так и для сервера.
* Сервер журналирования и все клиентские машины должны иметь прямые и обратные записи в локальной DNS. Если в сети нет DNS-сервера, создайте записи в файле [.filename]#/etc/hosts# каждой системы. Корректное разрешение имён необходимо для того, чтобы записи журналов не отклонялись сервером журналирования.

На сервере журналов отредактируйте файл [.filename]#/etc/syslog.conf#, указав имя клиента, от которого будут приниматься записи журнала, используемое средство ведения журнала и имя файла для хранения записей журнала данного хоста. В этом примере добавляется имя хоста `B`, регистрируются все средства и записи журнала сохраняются в файле [.filename]#/var/log/logclient.log#.

.Пример конфигурации сервера журналов
[example]
====

[.programlisting]
....
+logclient.example.com
*.*     /var/log/logclient.log
....

====

При добавлении нескольких клиентов для журналирования добавьте аналогичную запись из двух строк для каждого клиента. Дополнительную информацию о доступных средствах можно найти в man:syslog.conf[5].

Далее выполните следующие команды:

[source, shell]
....
# sysrc syslogd_enable="YES"
# sysrc syslogd_flags="-a logclient.example.com -v -v"
....

Первый параметр запускает syslogd при загрузке системы. Второй параметр разрешает записи журналов от указанного клиента. Опция `-v -v` увеличивает подробность записываемых сообщений. Это полезно для настройки категорий, так как администраторы могут видеть, какие типы сообщений записываются в каждой категории.

Можно указать несколько параметров `-a`, чтобы разрешить ведение журнала от нескольких клиентов. Также можно указывать IP-адреса и целые сетевые блоки. Полный список возможных параметров приведён в man:syslogd[8].

Наконец, создайте файл журнала:

[source, shell]
....
# touch /var/log/logclient.log
....

На этом этапе следует перезапустить и проверить syslogd:

[source, shell]
....
# service syslogd restart
# pgrep syslog
....

Если возвращен PID, сервер успешно перезапущен, и можно приступать к настройке клиента. Если сервер не перезапустился, проверьте ошибку в [.filename]#/var/log/messages#.

==== Конфигурация клиента журналирования

Клиент системы журналирования отправляет записи журналов на сервер журналирования в сети. Клиент также сохраняет локальную копию своих собственных журналов.

После настройки сервера журналирования выполните следующие команды на клиенте журналирования:

[source, shell]
....
# sysrc syslogd_enable="YES"
# sysrc syslogd_flags="-s -v -v"
....

Первый параметр включает запуск syslogd при загрузке системы. Второй параметр запрещает получение журналов от других хостов (`-s`) и увеличивает детализацию записываемых сообщений.

Затем определите сервер журналирования в файле [.filename]#/etc/syslog.conf# клиента. В этом примере все журналируемые источники отправляются на удалённую систему, обозначенную символом `@`, с указанным именем хоста:

[.programlisting]
....
*.*  @logserv.example.com
....

После сохранения изменений перезапустите syslogd, чтобы изменения вступили в силу:

[source, shell]
....
# service syslogd restart
....

Для проверки отправки журнальных сообщений по сети используйте man:logger[1] на клиенте, чтобы отправить сообщение в syslogd:

[source, shell]
....
# logger "Test message from logclient"
....

Это сообщение теперь должно присутствовать как в [.filename]#/var/log/messages# на клиенте, так и в [.filename]#/var/log/logclient.log# на сервере журналов.

==== Отладка серверов журналов

Если на сервере журналов не поступают сообщения, скорее всего, причина в проблеме с сетевым подключением, разрешении имён или опечатке в конфигурационном файле. Чтобы выявить причину, убедитесь, что и сервер журналов, и клиент могут `ping` друг друга, используя имя хоста, указанное в их [.filename]#/etc/rc.conf#. Если это не удаётся, проверьте сетевые кабели, набор правил межсетевого экрана и записи имён хостов на DNS-сервере или в [.filename]#/etc/hosts# как на сервере журналов, так и на клиентах. Повторяйте проверки, пока `ping` не будет успешным с обоих хостов.

Если команда `ping` выполняется успешно на обоих хостах, но сообщения журнала по-прежнему не поступают, временно увеличьте уровень детализации журналирования, чтобы сузить круг поиска проблемы в конфигурации. В следующем примере файл [.filename]#/var/log/logclient.log# на сервере журналирования пуст, а файл [.filename]#/var/log/messages# на клиенте журналирования не указывает на причину сбоя.

Для увеличения уровня отладочной информации отредактируйте параметр `syslogd_flags` на сервере журналирования и выполните перезапуск:

[source, shell]
....
sysrc syslogd_flags="-d -a logclient.example.com -v -v"
....

[source, shell]
....
# service syslogd restart
....

На консоли сразу после перезагрузки появится отладочная информация, подобная следующей:

[.programlisting]
....
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
Logging to FILE /var/log/messages
syslogd: kernel boot file is /boot/kernel/kernel
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
rejected in rule 0 due to name mismatch.
....

В этом примере сообщения журнала отклоняются из-за опечатки, которая приводит к несоответствию имени хоста. Имя хоста клиента должно быть `logclient`, а не `logclien`. Исправьте опечатку, выполните перезапуск и проверьте результат:

[source, shell]
....
# service syslogd restart
....

Вывод должен быть похож на следующий:

[.programlisting]
....
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
syslogd: kernel boot file is /boot/kernel/kernel
logmsg: pri 166, flags 17, from logserv.example.com,
msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
accepted in rule 0.
logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
Logging to FILE /var/log/logclient.log
Logging to FILE /var/log/messages
....

На данном этапе сообщения правильно принимаются и помещаются в нужный файл.

==== Безопасность

Как и в случае с любой сетевой службой, перед внедрением сервера журналирования следует учитывать требования безопасности. Журналы могут содержать конфиденциальные данные о службах, включенных на локальном хосте, учётных записях пользователей и конфигурации. Данные, передаваемые по сети от клиента к серверу, не шифруются и не защищаются паролем. Если требуется шифрование, можно использовать package:security/stunnel[], который передаёт данные журналирования через зашифрованный туннель.

Локальная безопасность также является важным вопросом. Журналы не шифруются ни во время использования, ни после ротации. Локальные пользователи могут получить доступ к файлам журналов для сбора дополнительной информации о конфигурации системы. Установка правильных разрешений для файлов журналов крайне важна. Встроенный ротатор журналов newsyslog поддерживает установку разрешений для вновь создаваемых и ротируемых файлов журналов. Установка режима `600` для файлов журналов должна предотвратить нежелательный доступ со стороны локальных пользователей. Дополнительную информацию можно найти в man:newsyslog.conf[5].

[[acpi-overview]]
== Управление питанием и ресурсами

Важно эффективно использовать аппаратные ресурсы. Управление питанием и ресурсами позволяет операционной системе отслеживать системные ограничения и, возможно, выполнять некоторые действия, вызванные событиями, связанными с этими ограничениями.

[[acpi-config]]
=== Конфигурация ACPI

На FreeBSD управление этими ресурсами осуществляется с помощью устройства ядра man:acpi[4].

[NOTE]
====
В FreeBSD драйвер man:acpi[4] загружается по умолчанию при загрузке системы.

Этот драйвер *нельзя выгрузить после загрузки*, так как системная шина использует его для различных взаимодействий с оборудованием.
====

В дополнение к man:acpi[4], FreeBSD имеет несколько специализированных модулей ядра для различных подсистем ACPI от производителей. Эти модули добавляют дополнительную функциональность, такую как управление скоростью вентилятора, подсветкой клавиатуры или яркостью экрана.

Список можно получить, выполнив следующую команду:

[source, shell]
....
% ls /boot/kernel | grep acpi
....

Вывод должен быть похож на следующий:

[.programlisting]
....
acpi_asus.ko
acpi_asus_wmi.ko
acpi_dock.ko
acpi_fujitsu.ko
acpi_hp.ko
acpi_ibm.ko
acpi_panasonic.ko
acpi_sony.ko
acpi_toshiba.ko
acpi_video.ko
acpi_wmi.ko
sdhci_acpi.ko
uacpi.ko
....

В случае, если используется ноутбук IBM/Lenovo, необходимо загрузить модуль man:acpi_ibm[4], выполнив следующую команду:

[source, shell]
....
# kldload acpi_ibm
....

И добавьте эту строку в [.filename]#/boot/loader.conf#, чтобы загружать модуль при запуске:

[.programlisting]
....
acpi_ibm_load="YES"
....

Альтернативой модулю man:acpi_video[4] является драйвер man:backlight[9]. Он предоставляет универсальный способ управления подсветкой экрана. Этот драйвер включён в стандартное ядро GENERIC. Утилита man:backlight[8] позволяет запрашивать и изменять яркость подсветки экрана. В этом примере яркость уменьшается на 10%:

[source, shell]
....
% backlight decr 10
....

[[cpu-power-management]]
=== Управление питанием процессора

`CPU` — это наиболее энергозатратная часть системы. Знание того, как повысить эффективность использования `CPU`, является важной частью нашей системы для экономии энергии.

Для правильного и эффективного использования ресурсов системы FreeBSD поддерживает такие технологии, как Intel Turbo Boost, AMD Turbo Core, Intel Speed Shift и другие, с помощью man:powerd[8] и man:cpufreq[4].

Первым шагом будет получение информации о процессоре с помощью выполнения следующей команды:

[source, shell]
....
% sysctl dev.cpu.0 <.>
....

<.> В этом случае цифра `0` обозначает первое ядро процессора.

Вывод должен быть похож на следующий:

[.programlisting]
....
dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc/bma
dev.cpu.0.cx_usage_counters: 3507294 0 0
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 3804us
dev.cpu.0.cx_lowest: C3 <1>
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 <2>
dev.cpu.0.freq_levels: 2267/35000 2266/35000 1600/15000 800/12000 <3>
dev.cpu.0.freq: 1600 <4>
dev.cpu.0.temperature: 40.0C <5>
dev.cpu.0.coretemp.throttle_log: 0
dev.cpu.0.coretemp.tjmax: 105.0C
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.delta: 65
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=none _UID=0 _CID=none
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU
....

<1> Наименьшее состояние Cx, используемое для бездействия процессора.
<2> Поддерживаемые процессором состояния Cx.
<3> Доступные в настоящее время уровни для CPU (частота/потребление энергии).
<4> Текущая активная частота CPU в МГц.
<5> Текущая температура процессора.

[NOTE]
====
Если информация о температуре не отображается, загрузите модуль man:coretemp[4]. В случае использования процессора AMD загрузите модуль man:amdtemp[4].
====

Как только информация о CPU станет доступной, самый простой способ настроить энергосбережение — позволить man:powerd[8] взять управление на себя.

Включите службу man:powerd[8] в [.filename]#/etc/rc.conf# для запуска при загрузке системы:

[source, shell]
....
# sysrc powerd_enable=YES
....

Также необходимо указать определённые параметры для man:powerd[8], чтобы сообщить ему, как управлять состоянием CPU, выполнив следующую команду:

[source, shell]
....
# sysrc powerd_flags="-a hiadaptive -i 25 -r 85 -N"
....

. `-a`: Выбирает режим, используемый при работе от сети переменного тока.
. `hiadaptive`: Режим работы. Подробнее см. в man:powerd[8].
. `-i`: Указывает уровень загрузки процессора в процентах, при котором адаптивный режим должен начать снижать производительность для экономии энергии.
. `-r`: Указывает уровень загрузки процессора в процентах, при котором адаптивный режим считает, что процессор работает, и повышает производительность.
. `-N`: Рассматривать время выполнения "nice"-процессов как время простоя при расчете нагрузки; т.е. не увеличивать частоту CPU, если он занят только "nice"-процессами.

И затем включите службу, выполнив следующую команду:

[source, shell]
....
# service powerd start
....

[[cpufreq]]
=== Управление частотой процессора

FreeBSD включает универсальный драйвер man:cpufreq[4], который позволяет администратору или программам, таким как man:powerd[8] и package:sysutils/powerdxx[], управлять частотой CPU для достижения желаемого баланса между производительностью и энергопотреблением. Более низкая настройка сэкономит энергию, уменьшая нагрев CPU. Более высокая настройка увеличит производительность за счёт большего энергопотребления и усиленного нагрева.

[[est]]
=== Intel(R) Enhanced SpeedStep(TM)

Драйвер Intel(R) Enhanced Speed Step(TM), man:est[4], заменяет универсальный драйвер man:cpufreq[4] для процессоров, поддерживающих эту функцию. Частота процессора может быть статически настроена с помощью man:sysctl[8] или скрипта запуска `/etc/rc.d/power_profile`. Дополнительное программное обеспечение, такое как man:powerd[8] или package:sysutils/powerdxx[], может использоваться для автоматической регулировки частоты процессора на основе его загрузки.

Все поддерживаемые частоты, а также ожидаемое энергопотребление, можно узнать, изучив дерева man:sysctl[3]:

[source, shell]
....
# sysctl dev.cpufreq.0.freq_driver dev.cpu.0.freq_levels dev.cpu.0.freq
....

Вывод должен быть похож на следующий:

[.programlisting]
....
dev.cpufreq.0.freq_driver: est0
dev.cpu.0.freq_levels: 3001/53000 3000/53000 2900/50301 2700/46082 2600/43525 2400/39557 2300/37137 2100/33398 2000/31112 1800/27610 1700/25455 1500/22171 1400/20144 1200/17084 1100/15181 900/12329 800/10550
dev.cpu.0.freq: 800
....

Частота на 1 МГц выше максимальной частоты процессора указывает на наличие технологии Intel(R) Turbo Boost(TM).

[[hwpstate_intel]]
=== Intel Speed Shift(TM)

Пользователи, работающие на новых процессорах Intel(R), могут заметить некоторые различия в динамическом управлении частотой при обновлении до FreeBSD 13. Новый драйвер для технологии Intel(R) Speed Shift(TM), доступной в определённых моделях, предоставляет возможность аппаратного изменения частоты ядер, в том числе для каждого ядра отдельно. FreeBSD 13 включает драйвер man:hwpstate_intel[4] для автоматического включения управления Speed Shift(TM) на поддерживаемых процессорах, заменяя старый драйвер Enhanced Speed Step(TM) man:est[4]. Значение `dev.cpufreq.%d.freq_driver` в man:sysctl[8] покажет, использует ли система Speed Shift.

Чтобы определить, какой драйвер управления частотой используется, изучите OID `dev.cpufreq.0.freq_driver`.

[source, shell]
....
# sysctl dev.cpufreq.0.freq_driver
....

Вывод должен быть похож на следующий:

[.programlisting]
....
dev.cpufreq.0.freq_driver: hwpstate_intel0
....

Это указывает на использование нового драйвера man:hwpstate_intel[4]. В таких системах OID `dev.cpu.%d.freq_levels` будет показывать только максимальную частоту CPU и указывать уровень энергопотребления `-1`.

Текущая частота процессора может быть определена путем проверки OID `dev.cpu.%d.freq`.

[source, shell]
....
# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq
....

Вывод должен быть похож на следующий:

[.programlisting]
....
dev.cpu.0.freq_levels: 3696/-1
dev.cpu.0.freq: 898
....

Для получения дополнительной информации, включая сведения о балансировке производительности и энергопотребления, а также о том, как отключить этот драйвер, обратитесь к справочной странице man:hwpstate_intel[4].

[NOTE]
====
Пользователи, привыкшие к использованию man:powerd[8] или package:sysutils/powerdxx[], обнаружат, что эти утилиты были заменены драйвером man:hwpstate_intel[4] и больше не работают как ожидалось.
====

[[graphics-card-power-management]]
=== Управление энергопотреблением графической карты

Графические карты стали неотъемлемой частью современных компьютеров. Некоторые графические карты могут потреблять чрезмерное количество энергии. FreeBSD позволяет настраивать определённые параметры для снижения энергопотребления.

В случае использования видеокарты Intel(R) с драйвером package:graphics/drm-kmod[] следующие параметры можно добавить в [.filename]#/boot/loader.conf#:

[.programlisting]
....
compat.linuxkpi.fastboot=1 <.>
compat.linuxkpi.enable_dc=2 <.>
compat.linuxkpi.enable_fbc=1 <.>
....

<.> Попытайтесь пропустить ненужные установки режимов во время загрузки.
<.> Включить энергосберегающие состояния C для дисплея.
<.> Включить сжатие кадрового буфера для экономии энергии

=== Приостановка/возобновление

Функция приостановки/возобновления позволяет перевести машину в состояние с низким энергопотреблением и возобновить работу системы без потери состояния запущенных программ.

[NOTE]
====
Для корректной работы функции приостановки/возобновления в системе должны быть загружены графические драйверы. В видеокартах без поддержки KMS следует использовать man:sc[4], чтобы не нарушить функциональность приостановки/возобновления.

Дополнительная информация о том, какой драйвер использовать и как его настроить, доступна в главе crossref:x11[x11, Система X Window].
====

man:acpi[4] поддерживает следующий список состояний сна:

.Поддерживаемые состояния сна
[options="header", cols="1,1"]
|===

|S1
|Быстрый переход в режим ожидания с сохранением в оперативной памяти. ЦП переходит в состояние пониженного энергопотребления, но большинство периферийных устройств остаются активными.

|S2
|Состояние с меньшим энергопотреблением, чем S1, но с теми же основными характеристиками. Не поддерживается многими системами.

|S3 (Режим сна)
|Режим приостановки с сохранением в ОЗУ. Большинство устройств отключается, и система перестает работать, за исключением обновления памяти.

|S4 (Режим гибернации)
|Приостановка с сохранением состояния на диск. Все устройства отключаются, и система прекращает работу. При возобновлении система запускается, как после холодного включения. *Пока не поддерживается в FreeBSD*.

|S5
|Система корректно завершает работу и выключается.

|===

[[configure-suspend-resume]]
==== Настройка приостановки/возобновления

Первым шагом будет определение типов состояний сна, которые поддерживает используемое оборудование, выполнив следующую команду:

[source, shell]
....
% sysctl hw.acpi.supported_sleep_state
....

Вывод должен быть похож на следующий:

[.programlisting]
....
hw.acpi.supported_sleep_state: S3 S4 S5
....

[WARNING]
====
Как упоминалось выше, FreeBSD *пока* не поддерживает состояние `S4`.
====

man:acpiconf[8] можно использовать для проверки корректности работы состояния `S3`, выполнив следующую команду. Если команда выполнится успешно, экран погаснет и компьютер выключится:

[source, shell]
....
# acpiconf -s 3
....

В подавляющем большинстве случаев функциональность Suspend/Resume предназначена для использования на ноутбуке.

FreeBSD можно настроить для перехода в состояние `S3` при закрытии крышки, добавив следующую строку в файл [.filename]#/etc/sysctl.conf#.

[.programlisting]
....
hw.acpi.lid_switch_state=S3
....

[[troubleshooting-suspend-resume]]
==== Устранение неполадок при приостановке/возобновлении работы

Много усилий было приложено, чтобы функции приостановки (Suspend) и возобновления (Resume) работали корректно и наилучшим образом в FreeBSD. Однако в настоящее время эти функции работают правильно только на некоторых определённых моделях ноутбуков.

Некоторые проверки можно выполнить, если система работает некорректно.

В некоторых случаях достаточно выключить bluetooth. В других — загрузить правильный драйвер для видеокарты и т.д.

В случае, если это работает некорректно, некоторые рекомендации можно найти на FreeBSD Wiki в разделе link:https://wiki.freebsd.org/SuspendResume[Приостановка/возобновление].

[[adding-swap-space]]
== Добавление swap-пространства

Иногда системе FreeBSD требуется больше места в подкачке. В этом разделе описаны два способа увеличения пространства подкачки: добавление раздела подкачки к существующему разделу или новому жёсткому диску и создание файла подкачки в существующей файловой системе.

Для получения информации о том, как зашифровать пространство подкачки, какие существуют варианты и почему это следует делать, обратитесь к разделу crossref:disks[swap-encrypting,"Шифрование раздела подкачки"].

[[new-drive-swap]]
=== Раздел подкачки на новом жёстком диске или существующем разделе

Добавление нового диска для раздела подкачки обеспечивает лучшую производительность по сравнению с использованием раздела на существующем диске. Настройка разделов и дисков описана в crossref:disks[disks-adding,"Добавление дисков"], а crossref:bsdinstall[configtuning-initial,"Проектирование разметки разделов"] рассматривает варианты разметки разделов и вопросы выбора размера раздела подкачки.

[WARNING]
====
Можно использовать любой раздел, который в данный момент не смонтирован, даже если он уже содержит данные. Использование `swapon` на разделе с данными приведёт к их перезаписи и уничтожению. Перед выполнением `swapon` убедитесь, что выбранный раздел действительно предназначен для добавления в swap.
====

man:swapon[8] может использоваться для добавления раздела подкачки в систему выполнением следующей команды:

[source, shell]
....
# swapon /dev/ada1p2
....

Для автоматического добавления этого раздела подкачки при загрузке добавьте запись в [.filename]#/etc/fstab#:

[.programlisting]
....
/dev/ada1p2 none swap sw 0 0
....

См. man:fstab[5] для объяснения записей в [.filename]#/etc/fstab#.

[[create-swapfile]]
=== Создание файла подкачки

[[swapfile-10-and-later]]
Эти примеры создают файл подкачки размером 512 МБ с именем [.filename]#/usr/swap0#.

[WARNING]
====
Файлы подкачки на файловых системах ZFS крайне не рекомендуются, так как подкачка может привести к зависанию системы.
====

Первым шагом является создание файла подкачки:

[source, shell]
....
# dd if=/dev/zero of=/usr/swap0 bs=1m count=512
....

Второй шаг — установить соответствующие разрешения для нового файла:

[source, shell]
....
# chmod 0600 /usr/swap0
....

Третий шаг — сообщить системе о файле подкачки, добавив строку в [.filename]#/etc/fstab#:

[.programlisting]
....
md none swap sw,file=/usr/swap0,late 0 0
....

Раздел подкачки будет добавлен при запуске системы. Чтобы добавить раздел подкачки немедленно, используйте man:swapon[8]:

[source, shell]
....
# swapon -aL
....
