Создание юнита rc.local для systemd

Оригинал: https://www.redhat.com/en/blog/replacing-rclocal-systemd 

От переводчика: Автор статьи, безусловно, шарит в теме, но она написана в 2019 году и с тех пор кое-что поменялось, так что описанный здесь метод отчасти некорректен. Читайте примечание в самом тексте, я там всё объясню.

****************************************************************

У меня недавно возникли две разные проблемы на двух хостах под управлением Линукс. Они требуют разных решений, но одним способом: надо запустить команду во время или сразу после загрузки системы.

Файл rc.local был — и в ряде случаев остается — местом, куда сисадмины прописывают команды, которые должны выполняться во время загрузки. Использование этого файла не просто устарело — я за два часа попыток не смог заставить его работать. Это несмотря на то, что в документации к systemd упоминается "генератор", который создает сервисы systemd из файла rc.local, если он существует (похоже, это не худший способ заставить прекратить чем-то пользоваться — сделать так, чтобы не работало).

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

    Разница между boot (аппаратная загрузка) и startup (запуск операционной системы)

Для настройки Линукс и решения проблем, возникающих при загрузке, важно понимать, процессы загрузки и запуска ОС. На самом деле, чтобы загрузить компьютер под управлением Линукс и чтобы он мог после этого работать нужны две разных последовательности событий: загрузка устройства (boot) и загрузка операционной системы (startup). Последовательность boot начинается с аппаратного включения и заканчивается инициализацией ядра и запуском системы инициализации. После этого управление передается прцессу startup, который завершает подготовку компьютера к работе. 

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

    1. BIOS Power-On Self-Test (POST) 
    2. Загрузчик (GRUB)
    3. Ядро
    4. Система инициализации (systemd)

Детальное описание обеих последовательностей загрузки вы можете найти в моей статье «Знакомство с процессами загрузки компьютера и запуска Линукс»: https://opensource.com/article/17/2/linux-boot-and-startup

    Локальные загрузочные скрипты

Иногда сисадмины добавляют в процесс загрузки системы команды для конкретной машины - например, для локального запуска процессов, не входящих в стандартную процедуру загрузки systemd. Можно создать сервисы systemd для каждой программы, которую вы хотите запускать при загрузке, но традиционный файл rc.local давал возможность прописать их все в одном исполняемом файле. В systemd тоже можно применить этот подход и поместить все команды в один файл. Это изящное решение упрощает последующее добавление новых команд, не требуя при этом создавать юниты для каждой.

Оно заключается в том, чтобы создать один сервис для systemd, а все необходимые команды поместить в исполняемый файл. Задача состоит из двух частей: очевидно, что первым делом надо создать сам исполняемый файл. Вторая часть - написание сервисного модуля (юнита) для systemd, который будет запускать этот файл.

      Создание исполняемого файла

Для сисадмина, знакомого с написанием bash-скриптов, это тривиальная задача. По сути мы напишем скрипт на баше и поместим его в каталог, который в соответствии с  Linux Filesystem Hierarchical Standard (FHS) предназначен для локальных бинарников - это /usr/local/bin. Можно возразить, что лучше поместить его в другой каталог, но я считаю, что логичней всего именно /usr/local/bin, так как в этом случае админу будет проще запускать его из командной строки при необходимости: этот каталог присутствует в переменной $PATH любого пользователя, включая рута. 

Создайте файл mystartup.sh с содержанием, указанным ниже, поместите его в /usr/local/bin и не забудьте сделать исполняемым. Путь к bash должен соответствовать вашему дистрибутиву. Например, в форках Дебиана путь будет /bin/bash.


#!/usr/bin/bash

################################################################################
# mystartup.sh
#
# This shell program is for testing a startup like rc.local using systemd.
# By David Both
# Licensed under GPL V2
#
################################################################################

# This program should be placed in /usr/local/bin

################################################################################
# This is a test entry

echo `date +%F" "%T` "Startup worked" >> /root/mystartup.log


Запустите эту программу из командной строки. После первого исполнения в каталоге /root должен появиться файл mystartup.log с датой и временем, а также с сообщением: "Startup worked". После создания лог-файла туда будут добавляться строки при каждом выполнении скрипта, чтобы вы могли убедиться, что он работает.

Запустите скрипт еще несколько раз. В результате должно получиться что-то вроде этого:


[root@testvm1 ~]#  mystartup.sh

[root@testvm1 ~]#  cat mystartup.log

2019-09-12 19:58:00 Startup worked

2019-09-12 19:58:17 Startup worked

2019-09-12 19:58:54 Startup worked

2019-09-12 19:59:00 Startup worked

2019-09-12 20:01:08 Startup worked

2019-09-12 20:04:01 Startup worked

2019-09-12 20:04:13 Startup worked

2019-09-12 20:06:11 Startup worked

2019-09-12 20:06:28 Startup worked

2019-09-16 09:51:21 Startup worked

2019-09-16 09:51:51 Startup worked


Теперь в файл mystartup.sh можно добавлять нужные вам при загрузке команды.

      Создание сервиса systemd

Сейчас мы создадим стандартный модуль службы systemd. Файл будет простой - он нужен только для того, чтобы скрипт mystartup.sh запускался при загрузке ОС. 

Создайте файл /usr/local/lib/systemd/system/mystartup.service со следующим содержимым:

################################################################################
# mystartup.service
#
# This service unit is for testing my systemd startup service
# By David Both
# Licensed under GPL V2
#
################################################################################
# This program should be placed in /usr/local/lib/systemd/system/.
# Create a symlink to it from the /etc/systemd/system directory.
################################################################################

[Unit]

Description=Runs /usr/local/bin/mystartup.sh

  
[Service]

ExecStart=/usr/local/bin/mystartup.sh


[Install]

WantedBy=multi-user.target


Делать его исполняемым не надо. Можно было бы поместить его и в /etc/systemd/system, но, поскольку он локальный, лучше в /usr/local.

* Примечание переводчика: дальше автор предлагает создать символьную ссылку на этот файл в каталоге /etc/systemd/system, но если вы это сделаете, то systemd пошлет вас на три буквы при попытке выполнить скрипт. На данный момент (сентябрь 2026 г.) надо выполнить команду типа systemctl enable mystartup (или, возможно, указать полный путь к скрипту). Тогда systemd сам создаст необходимую ссылку и добавит сервис в автозагрузку.

Если вы хотите запускать команды сразу после инициализации ядра (например, чтобы остановить парковку голов hdd),   то в строке WantedBy=multi-user.target надо прописать другой уровень: WantedBy=basic.target

      Протестируем сервис

Прежде чем перезагрузиться и проверить результат, протестируем юнит. Для начала убедимся, что systemd видит сервис:


[root@testvm1 ~]#  systemctl status mystartup

● mystartup.service - Runs /usr/local/bin/mystartup.sh

Loaded: loaded (/usr/local/lib/systemd/system/mystartup.service; linked; vendor preset: disabled)

Active: inactive (dead)

[root@testvm1 ~]#


Судя по выводу команды, юнит был распознан. Теперь давайте запустим сервис. Команда systemctl start запускает скрипт, но не добавляет сервис в автозагрузку

[root@testvm1 ~]#  systemctl start mystartup


Теперь загляните в лог-файл и проверьте, появилась ли там новая строка.

       Добавление сервиса в автозагрузку

Осталось только добавить сервис, чтобы он запускался при загрузке системы:


[root@testvm1 ~]#  systemctl enable mystartup

Created symlink /etc/systemd/system/multi-user.target.wants/mystartup.service →

/usr/local/lib/systemd/system/mystartup.service.

[root@testvm1 ~]#

        Заключительный тест

До перезагрузки давайте посмотрим, как можно использовать команду journalctl для просмотра только той части журнала, которая касается mystartup.service. Также эту команду можно использовать для проверки работы скрипта, поскольку systemd логирует все свои действия. 

Следующая команда с параметром -u показывает только строки журнала, относящиеся к юниту mystartup:


[root@testvm1 ~]#  journalctl -u mystartup

-- Logs begin at Mon 2019-04-15 22:50:27 EDT, end at Mon 2019-09-16 11:44:30 EDT. --

Sep 16 11:09:28 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

[root@testvm1 ~]#



Теперь давайте перезагрузимся и проверим логи:



[root@testvm1 ~]#  systemctl status mystartup

● mystartup.service - Runs /usr/local/bin/mystartup.sh

Loaded: loaded (/usr/local/lib/systemd/system/mystartup.service; enabled; vendor preset: disabled)

Active: inactive (dead) since Mon 2019-09-16 11:45:59 EDT; 1min 30s ago

Process: 819 ExecStart=/usr/local/bin/mystartup.sh (code=exited, status=0/SUCCESS)

Main PID: 819 (code=exited, status=0/SUCCESS)


Sep 16 11:45:55 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

[root@testvm1 ~]#  journalctl -u mystartup

-- Logs begin at Mon 2019-04-15 22:50:27 EDT, end at Mon 2019-09-16 11:47:45 EDT. --

Sep 16 11:09:28 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

-- Reboot --

Sep 16 11:45:55 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

[root@testvm1 ~]#

         Заключение

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

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

UPD: вскоре после публикации этой статьи я получил на электронную почту сообщение от Тома Мерфи. Он рассказал, что в самом systemd существует сервис rc-local. Я благодарен ему за письмо, так как не знал об этом.

Поддержку традиционного rc.local можно осуществить командой systemctl enable rc-local. Перечисленные в файле rc.local команды выполнятся при следующей загрузке. Разумеется, этой же командой можно запустить rc.local немедленно.

Тем не менее, rc.local по-прежнему остается устаревшим. Вот что написано в мануале для  systemd-rc-local-generator: «Поддержка /etc/rc.local сохранена только для совместимости с некоторыми системами на System V. На сегодняшний день мы настоятельно не рекомендуем пользоваться этим скриптом. Вместо этого следует создавать соответствующие юниты с нужными зависимостями для каждого скрипта, который должен запускаться при старте системы».

    ОТ ПЕРЕВОДЧИКА: Я выкладываю эти статьи прежде всего для тех, кто пытается приспособить линукс для домашнего использования, поэтому на всякий случай резюмирую по шагам:
    1. Создать скрипт и поместить его в /usr/local/bin. Приведенный в статье скрипт удобен тем, что дает возможность проверить его работу, но после заключительной проверки я бы на вашем месте закомментировала эту строку, особенно если у вас SSD.
    2. Написать юнит и положить его в /usr/local/lib/systemd/system/. На самом деле дома можно сразу кидать в /etc/systemd/system, но если хотите цивильно по правилам, то надо в /usr/local.  
    3, Если вы поместили юнит в /etc, можете сначала запустить юнит командой start, как написано в статье. Если поместили в /usr/local, то надо запускать командой systemctl enable servicename. Ссылку создавать вообще не надо.

        Использованные ресурсы:

Здесь некоторые названия ссылок говорят сами за себя, поэтому я не стала уточнять, что это. 

        Linux Filesystem Hierarchical Standard (FHS):  http://www.linux-databook.info/?page_id=2609

        https://en.wikipedia.org/wiki/GNU_GRUB

        https://www.gnu.org/savannah-checkouts/gnu/grub/manual/grub/grub.html

        https://en.wikipedia.org/wiki/Master_boot_record

        https://en.wikipedia.org/wiki/Multiboot_specification

        https://en.wikipedia.org/wiki/Systemd    

        Systemd bootup process: https://www.freedesktop.org/software/systemd/man/latest/bootup.html?__goaway_challenge=meta-refresh&__goaway_id=d2d3dc1830f49b19c195b6a9b4bce98c&__goaway_referer=https%3A%2F%2Fwww.redhat.com%2F
        List all manpages from the systemd project: https://www.freedesktop.org/software/systemd/man/latest/index.html

        An introduction to the Linux boot and startup processes: https://opensource.com/article/17/2/linux-boot-and-startup?extIdCarryOver=true&sc_cid=RHCTG0180000382526

Решение проблемы со спящим режимом на HP Probook

 У меня большая радость в личной жизни: я разобралась со спящим режимом. Краткая предыстория: у меня на ноуте hp probook с прошивкой uefi под линуксом есть проблема, о которой я читала много раз в блогах (например, блог дебиана, арча и LQ). Точнее, даже две проблемы, которые, судя по сообщениям в блогах, часто приходят вместе: 

1. Ноут зависает в простое. Экран гаснет и аппарат перестает реагировать на любые тычки клавиатуры, мыши и тачпада, кроме долгого нажатия на power. Но в моем случае это фигня, я просто запускаю screensaver и он может простаивать как угодно долго. Кстати, фризится он у меня только на дебиан, а на слаке вместо этого перезагружается.

2. Ноут не уходит в suspend или не выходит из него. Ну то есть, например, при попытке перевести его в susoend-to-RAM индикатор вайфая становится оранжевым (то есть беспроводная карта отключается), остальные продолжают гореть и ноут больше ни на что не реагирует, кроме, опять же, выключения долгим зажимом power. 

Я сразу подозревала, что причина в сетевом стеке (точнее, видимо, в его взаимодействии с прошивкой, потому что на ноутах с bios всё работает), но не сразу поняла, как отключить ВСЁ: я то забывала про хрони, то ждала слишком мало.

РЕШЕНИЕ для Slackware 15.0 и для Debian 13 у меня отличается, поскольку дебиан установлен через debootstrap и там нет нетворкменеджера и тому подобного, а в слаке есть.

1. Slackware

bluetooth отключен через rfkill в rc.local; NetworkManager перед саспендом надо остановить - /etc/rc.d/rc.networkmanager stop. Сетевые приложения типа браузера я перед этим закрываю. Ещё был подлый ModemManager, который невозможно было убить командой kill, так как он сразу запускался заново. Сносить его я не стала, потому что однажды попыталась удалить wayland, которым все равно не пользуюсь, после чего перестал запускаться... FIREFOX. Короче, я просто сняла с его бинарника бит исполнения: chmod -x /usr/sbin/ModemManager  Еще приходится останавливать chronyd через kill -s 15 или killall. 

А теперь неочевидная часть: после этого надо еще несколько минут подождать (я раньше пыталась, но, видимо, мало ждала. В слаке надо ждать дольше, чем в дебиане), и тогда suspend работает на ура как через /sys/power/state,  так и через loginctl suspend.

2. Debian

Блютус отключен. Закрываю браузер, останавливаю wpa_supplicant (например, через команду terminate в wpa_cli) или dhcpcd для проводной сети (dhcpcd -x ifname). Chrony здесь можно не останавливать - без сети он сам отключается. Тоже надо подождать пару минут, потом systemctl suspend.

МОЙ ОЧЕРЕДНОЙ ДИСТРОХОП, ОТЗЫВ О Debian 13.5, ТЕКУЩАЯ СИТУАЦИЯ В ЛАГЕРЕ Линукс.

 У меня уже есть несколько постов про ноут HP Probook 430 G3, на котором спящий режим работает в slackware-15.0 stable через задницу. Одно время проблема вроде как решилась отключением elogind, но продлилось это несколько дней, потом опять он перестал уходить в suspend-to-RAM нормально - ну то есть уходил рандомно, а чаще не уходил. Архитектура процессора skylake, прошивка uefi, и это, видимо, роляет, потому что на старом компаке с bios та же система работает как часы. Memtest ничего не показал, хотя бывает, что память битая, а он не видит. В мануале к ноуту написано, что он поддерживает линукс, ОСОБЕННО убунту какой-то древней версии. К убунту я была морально не готова, поэтому решила попробовать дебиан. Ну мало ли - вдруг systemd будет работать лучше. Хотя я сомневалась, потому что на серверах спящего режима нет и корпораты вряд ли особо стараются его поддерживать. Но зато у дебиана поддержка чуть ли не 10 лет и репозиторий понасыщенней, чем EPEL и ELREPO.  

    ● Что там с другими линуксами, в том числе без systemd?

В клонах EL мало пакетов - то, чего нет в EPEL, надо дергать из Федоры, а зачем, если есть другие дистры. Кстати, Федора дропнула поддержку X11 и полностью перешла на wayland.

Моим первым дистром был Open Suse, и я сначала глянула, как там дела. На ЛОРе как раз была тема про новый релиз Leap-16. Отзывы о нем выглядели примерно так: просрали все полимеры, руки поотрывать и т.п. Короче, там теперь новый установщик, а панель администрирования yast разделили на две части: одна для пакетного менеджера, вторая для остального. На Reddit тоже были англоязычные отзывы, и там народ был недоволен, что из панели убрали некоторые функции и теперь придется руками править конфиги. Зато и установщик, и панели имеют веб-морду (первый, вроде как, на базе firefox). В общем, я поняла, что туда сейчас лучше не соваться, потому что сама свалила с сусе как раз в момент, когда они уходили от Novell и пилили свой первый Leap. До этого всё было прекрасно (хотя я допиливала его руками, но меня это никогда не пугало), а потом версии стали одна стремнее другой и я не выдержала.

Без системГэ я знаю один неплохой дистр - год назад там не было никаких elogind и вроде даже pam. Пожалуй, это единственный дистр на sysV, кроме слаки, который не считается маргинальным, так как популярен в Штатах - это PCLinux, форк Мандрейка. Роллинг, но когда я имела с ним дело (в течение пары лет), он был очень стабильным. Он стоял у моей матери, но она там кое-что нахеровертила и убила систему. Так как я сама пользовалась слакой, то и ей поставила, чтобы глаза не разбегались лишний раз. В принципе, когда я в последний раз ставила слаку, то рассматривала его, но там, во-первых, очень мало пакетов в репозитории (раньше было больше). На самом деле в слаке их тоже мало, но там можно подключить реп бинарно совместимого с ней Salix Os, а для остального есть слакбилды. Есть, кстати, еще slackonly, но из него можно ставить только в ближайшее время после выхода релиза, пакеты там не обновляются. Но зато, как и реп Salix, он тоже не васянский, в отличие от AUR и подобных. Во-вторых, его тоже пришлось бы допиливать: кроме правок конфигов, которые у меня уже есть на флешке, мне пришлось бы сносить displaymanager, переводить sysv в другой ранлевел (там уровни отличаются от sysv в слаке), ставить fluxbox и все такое, чего в слаке делать не надо. Но я все же посмотрела в эту сторону и узнала, что у главного разработчика PCLOS Билла уже больше десяти лет рак. Я даже увидела его давний пост, где он пишет, что, мол, "cancer is kicking my ass". Там, конечно, есть сообщество, но я так поняла, что основной план такой: если Билл вдруг отъедет, то вместо нынешнего дистра будет PCLinux debian edition. А там вообще изначально пакетник был rpm, но в качестве морды к нему apt и synaptic. Потом они пробовали редхатовский dnf, но я не в курсе, как он у них прижился.   

А, есть же еще отечественные операционные системы. Вот, например, Alt Linux, который похож на PCLOS тем, что там тоже rpm, apt и synaptic. На его эмблеме один пингвин сосет у другого, и это неспроста. Помню, когда я еще пользовалась XFCE, то полезла гуглить какую-то проблему и наткнулась на форум альта. Там пользователь задал вопрос, а ему ответили вот так: "Потому что пользователи gtk должны страдать". При этом у них была официальная сборка с XFCE. Это всё, что мне надо было знать об Alt Linux.

Void и Crux я уже пробовала, но как-то не зашло (в войде musl тогда работал хреново, в Круксе надо собирать руками слишком много, нафига мне этот менингит), так что решила для начала поставить дебиан, стабильности которого фанаты поют дифирамбы. Тем более, что версии пакетов в stable там уже не старше, чем сейчас в слаке, а ядро даже новее. 

    ● Debian

Сначала я записала образ на флешку, но он при установке потребовал вставить диск. Я заподозрила, что флешкой что-то не то, записала еще раз, после чего ноут перестал ее видеть. Да и х** с ней, подумала я и поставила систему через debootdstrap.  

Всё встало, я перешла в chroot, установила ядро, нужные прошивки, dhcpcd, ещё там что-то типа util-linux и загрузилась в новую ось через GRUB, который уже стоял в слаке и распознал дебиан. Дебиан встретил меня поросячьим визгом спикера прямо в консоли - такого я никогда не видела. Я решила разобраться с этим позже и поковырялась в системе, обнаружив, что надо еще ставить pciutils, usbutils и всё такое. Короче, при установке через deboostrap ставить придется всё, кроме apt. Вместо sudo я пользуюсь su. Так вот, в слаке su сконфигурирован так, что если вы даете команду "su", то подразумевается "su -". В дебиане это не так и после su вы не сможете просто выполнять команды, лежащие в /sbin или /usr/sbin, по названию без полного пути. Я пару раз успешно перевела ноут в спящий режим через systemctl и стала ковыряться дальше.

Накатила иксы и fluxbox, firefox (там два браузера - firefox и chromium, как и в последней слаке. Всяких slimjet и opera в репозиториях больше нет), и полезла смотреть, что за херня со спикером (он продолжал визжать в терминале sakura). Оказывается, это не баг, а фича, и если вы хотите заткнуть фонтан, там предлагается отредактировать файл inputrc, а если не поможет, то просто удалить драйвер для спикера. Охеренно придумано,конечно, но я потом отключила его через xset -b, а для консоли просто убавила звук в пульсе. Не могу не упомянуть, что загружается он дольше, чем слака, хотя именно ускорение загрузки позиционировалось когда-то главной целью Гэ.

А, сначала же я подняла сеть. Я не стала ставить NM и мне было лень разбираться с их скриптами, поэтому, чтобы пользоваться беспроводной картой, я просто поставила wpa-supplicant и подняла сеть в первый раз через wpa_cli. Проводная работает через dhcpcd. Net-tools искаропки там нет (а в слаке есть), так что запомните: ip addr show; ip link set XXXX up.

Дальше был gkrellm. Я увидела в репозитории плагин gxkb для него и на радостях установила, но он не отображался. Так же, как и в слаке, при попытке сменить тему во fluxbox иксы иногда падают. А хотите узнать дистрибутив, где не падают и gkrellm-gxkb отображается? Пожалуйста: freebsd. Я в курсе, что там могут отваливаться беспроводные карты, но по какой-то иронии судьбы на моих ноутах именно во фряхе сеть работала лучше всего. Но там другие загоны с вращением вентилятора. Более того, в дебиане как-то раз у меня из gkrellm исчез индикатор батареи. Я заглянула в настройки, там галка стоит - батарея, что ли, внезапно сдохла? Ну просто если исчезает индикатор сети, значит, сеть отвалилась. А, нет, батарея целая, после перезапуска gkrellm индикатор появился. Н-да. 

Проверила звук. Там вообще-то предполагается pipewire, но я поставила pulseaudio, потому что в слаке оно работает нормально, звук не пердит (хотя в прошлой версии иногда бывало). Зжесь тоже все нормально, по крайней мере, у меня. В браузерах звук был сразу.

Как я и подозревала, через какое-то время начались проблемы со сном. Кстати, в Дебиане есть пакет pm-utils, которого, я думаю, уже больше нет нигде. Похоже, некоторые его майнтейнеры достигли просветления. В отличие от SUSE, где sysV больше не поддерживается, в дебиане еще как поддерживается и, более того, в их вики написано, что если раньше удаление Гэ вызывало проблемы, то теперь без него будет работать и гном, и все остальное. Я нашла проблему с systemd в системном журнале. journalctl умилил меня тем, что урезал вывод. Ну типа если проматывать стрелочкой наверх, то вы увидите всё, но это займет некоторое время. Чтобы такой херни не было, надо делать так: journalctl --no-pager|less. Честно говоря, less /var/log/messages мне нравится больше. Конфиг systemd я исправила, как было написано в каком-то unixforum или типа того, но, как обычно, эффекта хватило не надолго.

Решила я обновиться. но apt начал ругаться на реп обновлений безопасности, указанный в конфиге по умолчанию. Короче, там есть ещё cdn-fastly. Соответствующую строчку я заменила на это:

deb http://cdn-fastly.deb.debian.org/debian-security stable-security main

и все заработало. Обновлений было немного. В слаке мне еще нравится один нюанс: там пакетов мало, но они большие, что весьма полезно для ssd. В дебиан, в принципе, тоже по сравнению с PCLOS или, тем более, Open SUSE с этим весьма неплохо. Например, qpdfview хоть и не один пакет, как в слаке, но два, это тоже немного.

    ● Впечатление от системы

Честно говоря, тем, что все работает и не ломается при обновлениях, после десяти лет на slackware stable меня не удивишь. Кроеме того, не надо забывать, как я поставила систему. Если бы установка была из нормального образа, то телодвижений было бы гораздо меньше, а может, и работало бы что-то лучше. Общее впечатление вкратце такое: для домашнего использования слака и даже фряха приспособлены лучше. Дебиан всё же серверный.  Systemd, на мой взгляд, дома не нужен, так как плодит сущности, которые не факт, что вам нужны, и проявляет самостоятельность. В продакшене он удобен тем, что сразу подхватывает сервисы и не надо лишний раз ковырять конфиги руками. Например, chrony интегрирован в systemd. В слаке он ставится либо из слакбилда, либо из репы саликса. Но там надо руками создать группу и пользователя chrony и самому его запустить. В Дебиане ставишь его через apt, группа и юзер создаются сами, демон запускается и автоматически оказывается в автозагрузке (даже если вы не планировали запускать его прямо сейчас и ставить в автозагрузку).

Но, сука, как доходит до GUI, все меняется - по крайней мере, для пользователей WM, а не DE. В слаке есть утилита xwmconfig. Я не понимаю людей, которые сидят дома за компом одни и пользуются дисплейменеджером - это же средство контроля доступа, которое будет постоянно висеть в фоне и жрать ресурсы без всякого смысла. Ну вот, в слаке запускаешь xwmconfig (он на ncurses), там в списке все gui, которые там были и которые ты сам устанавливал, тыкаешь пару раз на клавишу и заходишь в нужное окружение. А вот в дебиане есть choosewm, но работает через жопу. В общем, я поставила то, чем обычно пользуюсь: fluxbox и windowmaker. В слаке они запускаются просто через startx, а там надо startx /usr/bin/startfluxbox или startx /usr/libexec/WindowMaker/wmaker - до последнего еще надо додуматься. Fluxbox в слаке сконфигурирован удобней, чем в дебиане, gkrellm не глючит. Но suspend на дебиане работает чаще.

Кроме того, Слака жрет чуть меньше памяти, быстрее загружается. Но в этой версии после обновления были проблемы в виде тормозов при авторизации, которые пропали после другого обновления на Compaq и остались на Probook. Про дебиан ничего не могу сказать, так как пользуюсь им без году неделю. По доступности пакетов  в репозиториях примерно одинаково, но только для меня. В слаке нет, например, гнома, хотя есть репозитории, откуда можно накатить и его, и Гэ, но это все будут телодвижения. При этом практически все производители софта, если он имеет версию под линукс, выкладывают деб-пакет на своих сайтах. У слаки здесь все печальней. А, кстати, в слаке wps-office есть в слакбилдах. Но зато для дебиана есть пакет на офсайте. О том, как я не смогла загрузить нормальный пакет и попользовала китайский wps, расскажу отдельно.

В общем, не могу сказать, что дебиан говно, но слака мне нравится больше. Вот поэтому, сука, я до сих пор на ней и сижу: практика неоднократно показала, что если в ней есть проблема, то это проблема самого ядра или Xorg и т.п., и в другом линуксе она, скорее всего, никуда не денется. Единственное, что раньше в слаке не работал networkmanager, хотя и стоял из коробки, а в других дистрах работал. Но в слаке для этого был wicd. Кроме этого случая, я не могу вспомнить, чтобы где-то было лучше, чем на слаке, а вот хуже лично для меня - это да.
 

Как я чинила спящий режим на hp probook 430-G3: виды режимов сна и управление suspend через интерфейс ядра линукс

 Я уже писала про этот ноут ― там была проблема со спящим режимом на slackware 15.0. После перехода в S2RAM он сразу просыпался, а если выбрать s2ide, то, наоборот, невозможно было его разбудить. Я особо не дёргалась по этому поводу, потому в простое он нагревается где-то до 30-34 градусов, вся периферия уходит в сон, особенно после настройки через powertop, ну и я, честно говоря, была почти уверена, что проблема в прошивке - типа кривых таблиц acpi, - потому что не работает Fn и кнопки отключения wifi и звука. Но всё равно меня подбешивало, поэтому как-то на досуге я решила выяснить, в чем на самом деле проблема. В итоге я выяснила, но спойлерить не буду, а то получится не так захватывающе, как это было для меня.

    1. ВИДЫ РЕЖИМОВ СНА В БОЛЕЕ-МЕНЕЕ СОВРЕМЕННЫХ НОУТБУКАХ

 
● S0 (connected suspend/modern suspend/s2idle) ― это как в планшетах и смартфонах: поддерживается wi-fi соединение, фоновые обновления почты и приложений даже при закрытой крышке.

● S1 (standby/power on suspend) ― состояние сна в acpi, когда CPU прекращает выполнять команды, останавливает тактовые генераторы и сбрасывает кэши, но питание на компоненты, включая RAM, подаётся.

● S2 (standby/shallow) ― промежуточный, встречается редко. Напряжение может подаваться на некоторые компоненты материнской платы.

● S3 (suspend to RAM) - все компоненты обесточены, кроме RAM, где сохраняется состояние системы.

● S4 ― гибернация.

    2. ИНТЕРФЕЙС ЯДРА ДЛЯ УПРАВЛЕНИЯ СПЯЩИМ РЕЖИМОМ ИЗ ПРОСТРАНСТВА ПОЛЬЗОВАТЕЛЯ
    оригинал:    https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html 

Это каталог /sys/power

    ■ Значение файлов и настройка:

● state ― содержит поддерживаемые ядром состояния сна. У меня это были disk (гибернация) и freeze (s2idle). Третье значение mem интерпретируется в зависимости от содержания файла mem_sleep.

● mem_sleep ― содержит доступные режимы сна и позволяет выбрать вариант, который будет ассоциирован с параметром mem из файла /sys/power/state. Ассоциированный параметр будет взят в квадратные скобки. Если ядро не поддерживает сон, этого файла не будет. У меня там было два варианта: deep (s2RAM) и s2idle. На некоторых ACPI-based системах, которые берут информацию из таблиц ACPI, по умолчанию стоит s2idle, даже если поддерживается s2RAM, но обычно последний стоит по умолчанию. Чтобы выставить параметр по умолчанию, можно либо либо использовать 'echo deep > /sys/power/mem_sleep', либо сделать это через параметр ядра "mem_sleep_default", передав его загрузчику.

    ■ Два способа перевести машину в  S2idle

I   echo freeze|sudo tee /sys/power/state

II  echo s2idle|sudo tee /sys/power/mem_sleep
    echo mem|sudo tee /sys/power/state

    ■ Единственный способ перевести в S2RAM 

     echo deep|sudo tee /sys/power/mem_sleep
     echo mem|sudo tee /sys/power/state

Собственно, теперь я так и перевожу ноут в сон.

    3. ПОЧЕМУ НОУБУК САМОПРОИЗВОЛЬНО ВЫХОДИТ ИЗ СНА

Первое, что выдаст вам гугл по этому поводу, файл /proc/acpi/wakeup. Типа надо убрать оттуда лишнее, тогда всё заработает. Надо смотреть на enabled. Это если не смотреть специфичные для слаки решения. На LQ я нашла совет поменять elilo на grub и поставить новое ядро. Короче, теперь у меня grub и ядро 6.12.82, но проблему это не решило. 

Ну вот мой вывод:

bash-5.1# cat /proc/acpi/wakeup |grep en
XHC      S0    *enabled   pci:0000:00:14.0
RP05      S4    *enabled   pci:0000:00:1c.0
PXSX      S4    *enabled   pci:0000:01:00.0
RP06      S4    *enabled   pci:0000:00:1c.5
RP09      S4    *enabled   pci:0000:00:1d.0

Как видите, S3 здесь вообще не фигурирует, а для S0 стоит XHC, это extensible host controller, который управляет usb 3.0/3.1. Между тем ноут просыпается из обоих режимов только по кнопке питания, дёрганье мыши, нажатия на тачпад или встроенную клаву на него не действуют.

Параметр wakeonlan у меня отключен в прошивке, /sys/class/net/wlan0/device/power/wakeup показывает "disable". Тем не менее, я пыталась отключать сеть и ноут действительно переходил в S3, но только один раз. В следующий раз он опять мигал индикатором батареи и просыпался примерно через минуту. Ну и, собственно, в S3 он, похоже, не переходил: экран гас, но кнопки продолжали светиться как обычно, тогда как в s3 кнопка вайфай становится оранжевой, а power начинает мигать.

В качестве GUI у меня fluxbox и windowmaker, то есть никаких своих менеджеров питания, которые сбрасывали бы настройки elogind, нет. В сон я переходила командой loginctl suspend. 

    4. ФОКУСЫ ПИДОРСКОГО elogind

Этот шлак был у меня сконфигурирован вроде правильно в файле /etc/elogind/logind.cong, но оказалось, что у него есть один нюанс - ингибиторы. Это программы, которые не дают машине перейти в сон, пока что-то там не завершат. Вот команда для просмотра ингибиторов, если у вас нет systemd: 

bash-5.1# dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.ListInhibitors

А вот её вывод в первый раз: 

      struct {
         string "sleep"
         string "NetworkManager"
         string "NetworkManager needs to turn off networks"
         string "delay"
         uint32 0
         uint32 1129
      }
      struct {
         string "sleep"
         string "ModemManager"
         string "ModemManager needs to reset devices"
         string "delay"
         uint32 0
         uint32 1216
      }

Я остановила NM, и ноут заснул. Но сделав это во второй раз, получила хрен на блюде. Посмотрев ингибиторы, я увидела, что там добавился ещё Upower. Если убить его командой kill, то ноут опять засыпал,  но в третий раз опять что-то вылезало. Короче, мне надоело это блядство и я просто отключила нахрен elogind, сняв бит x с его скрипта в /etc/rc.d. Кроме того, он влияет на pam ― у меня после одного из обновлений это стало проявляться тормозами при авторизации пользователей как в консоли, так и в терминале GUI. Я обнаружила его, когда смотрела лог авторизации (в слаке это /var/log/secure). Короче, надо ещё сделать так:

bash-5.1# grep elogin /etc/pam.d/*

и закомментировать строчки, содержащие elogind, в файлах, которые вы используете.
Также я установила nologind из репозитория Salix OS, ну типа чтобы нормально работал powerkit, хотя я не уверена, что он был нужен, но мне надоело видеть ошибки и возиться лишний раз. Seatd я ставить не стала, потому что нахрен он нужен, когда в системе два пользователя, и оба ― ты сам.

    ЭПИЛОГ: теперь я выключаю и перезагружаю ноут командой shutdown, а в сон перевожу через описанный выше интерфейс ядра. У меня ничего не тормозит и всё работает, но я опять покосилась в сторону freebsd ― скорее рефлекторно, ведь там со спящим режимом всё ещё хуже и, кроме того, обороты вентилятора хрен настроишь, если модуль wmi не поддерживает твоё железо. Но знаете, я обнаружила, что утилиту ataidle, которая останавливала парковку головок hdd, похоронили, добавив этот функционал в стандартный camcontrol. В общем, если они разберутся с вентиляторами и саспендом и я на тот момент ещё буду жива, то с удовольствием пошлю линукс на три буквы. 

UPD: проблема решена

 описание здесь: https://bjdarticles.blogspot.com/2026/08/hp-probook.html

Отзыв об HP Probook 430 G3, нюансы его прошивки, управление частотой процессора в данном ноуте и вообще в ядре линукс, начиная с 5-й версии.

 Предыстория

У меня перестали реагировать на нажатие некоторые клавиши встроенной клавиатуры на ноуте Asus K-50ip. Оказалось, это частично крякнул мультиконтроллер. Можно было заменить за 3 рубля, но я не стала, потому что там всратый чипсет от nvidia, куда интегрированы северный и южный мосты, а также видеокарта Geforce. Разумеется, всё это греется как утюг и, кроме того, прибито к материнской плате, то есть заменить его можно только с ней. В общем, я решила, что чинить его экономически нецелесообразно.

Пришлось рыскать в поиске вменяемой комиссионки, так как покупать новый ноут сейчас в РФ означает как минимум заплатить неадекватные качеству деньнги, а чаще при этом еще и получить говняное поделие. Подержанный HP, Dell или Acer всяко лучше, чем новый ирбис, прости господи, или китайский шлак. Про подержанный Asus я такого не скажу, потому что там чаще всего плохая система охлаждения, хотя полагаю, что и у них есть удачные модели.

Мои требования, нюансы режима турбо и обновления прошивки

Нашла я один магазин у черта на рогах с нормальными отзывами и каким-то выбором. Мне нужен был ноут на intel без дискретной видеокарты и режима турбо, чтобы не грелся и не выебывался. Просто у моего друга Санька был ноут с турбо - новый HP Elitebook (в 2014-15 году стоил около 100 000). Этот турборежим невозможно было отключить в прошивке: галка была, но если ее поставить, система не загружалась. А когда он был включен, питания от сети не хватало и использовалась батарея. Через пару месяцев после окончания гарантии батарея вздулась. Саня купил новую и, пошарившись в интернетах, решил обновить прошивку, так как в новой версии было умное управление аккумулятором: он не заряжался выше 80% и не разряжался ниже 20. После обновления он получил умное управление зарядом, а также проблему с прокруткой у тачпада (которая была только под линуксом, а не в винде - у него был дуалбут) и, самое хреновое, кулер перестал увеличивать обороты, в результате процессор начал греться в обеих ОС. На сайте HP он узнал, что раньше обновления можно было откатить, но не в этот раз. Техподдержке HP уже кто-то задал такой вопрос и был послан на три буквы. В общем, когда увидите совет обновить прошивку, подумайте десять раз.

Характеристики ноутбука

В итоге я выбрала hp probook, хотя диагональ у него 13,3", всё остальное идеально: проц Pentium 4405U без турбо - 2 ядра/4 потока; 8 ГБ DDR4; встроенная видяха, есть ethernet, три порта usb; SSD на 256 ГБ с нормальным смартом, родная батарея с износом 20%. Заряд держит больше 3-x часов (благодаря ssd, маленькому экрану и тому, что там вентилятор периодически отключается); заряжается быстро - т.е. состояние элементов питания хорошее. В отзывах про него часто поливают дерьмом матрицу, но меня она устроила: яркая и контрастная, цветопередача с уклоном в зелёный (а не в синий или фиолетовый). На матрице несколько тонких полос - отпечатков от клавы, обусловленных тем, что в более-менее новых ноутах нет зазора между экраном и клавой и при регулярном закрытии крышки стирается антибликовое покрытие. Замена матрицы такого размера у нас стоит около 6 косарей (это дёшево), но сервисник сказал, что смысла особо нет, потому что она опять протрётся. 2018 год выпуска, корпоративный сегмент.

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

Вопросы типа есть ли слот для памяти и винта не стоят - там даже процессор BGA.

Нюансы прошивки

Теперь, собственно, о нюансах - они касаются управления частотой процессора и спящего режима. Сразу скажу, что это фокусы прошивки, которую, судя по показаниям /sys/devices/virtual/dmi/id/bios_date, обновили в 2024 году.

Моя операционная система Slackware64 15.0. Клавиши, которые в сочетании с Fn регулируют яркость экрана, громкость и всё такое, на линуксе не работают, да и хрен с ними. Яркость я выставила в rc.local, прописав туда echo 800 > /sys/class/backlight/intel_backlight/brightness. 

Проблема со спящим режимом: если в прошивке поставить галку на пункте, который позволяет процессору снижать частоту, то ноут нормально засыпает только при закрытой крышке (напоминаю, что от постоянного хлопанья крышкой стирается покрытие на матрице, а также перетирается шлейф матрицы). Если крышку не закрыть, то через несколько секунд после засыпания один раз мигает индикатор батареи, ноут выходит из сна и при этом ещё перезагружается. Если галку снять, то процессор будет постоянно молотить на самой высокой частоте (кроме простоя), зато после команды loginctl suspend ноут спит с открытой крышкой. При этом ещё надо снять галку с Deep sleep и Extended idle power states.

Смысл некоторых пунктов прошивки (они описываются в руководстве:  https://kaas.hpcloud.hp.com/pdf-public/pdf_12904670_en-US-1.pdf  Наывается HP PC Commercial BIOS (UEFI) Setup Administration guide)

Меню Advanced, подменю Power Management

1.  Runtime power management - галка, которую надо поставить, чтобы можно было управлять частотой ЦПУ. Без неё он постоянно работает на максимальной. Но если у вас уже выставлен режим powersave через операционную систему, снятие галки ничего не изменит и suspend не получится. 
2.  Extended idle power states - позволяет процессору переходить в более глубокие состояния сна в простое.
3.  Power Control - при поставленной галке ноутбук поддерживает приложения для управления питанием типа APM+ - это прикол корпоративного сегмента, дома она вряд ли нужна.

Настройка частоты процессора в ядре линукс, начиная с 5-й версии. 

Мне надо, чтобы меньше грелось, но при этом не тормозило. Раньше она настраивалась через драйвер acpi-cpufreq или intel_pstate и всё, но теперь, чтобы снизить температуру, сначала надо выставить это, если там стоит "menu" вместо "ladder":

1. echo 'ladder' > /sys/devices/system/cpu/cpuidle/current_governor

2. echo 'fair_share' > /sys/devices/virtual/thermal/thermal_zone#/policy

Здесь # - номер зоны, надо выставить для всех. По умолчанию там step_wise.

Я вычитала это  на LWN... А, нет,  просто заметила, что как-то сильно греется, несмотря на настроенный cpufreq, и посмотрела dmesg. Там обнаружились governor menu и governor step_wise. После этого я нашла их по названию в системе. Капец.  

Дальше уже настройки intelpstate или acpicpufreq (у меня на этом ноуте первое). В cpufreq я пользуюсь регулятором conservative. В intelpstate надо поменять две настройки:

3. echo 'powersave' > /sys/devices/system/cpu/cpufreq/policy#/scaling_governor

После этого можно будет изменить вторую:

4. echo 'balance_power' > /sys/devices/system/cpu/cpufreq/policy#/energy_performance_preference

Честно говоря, я не читала, как работают разные настройки, но  здесь их пять: default,  performance,  balance_performance,  balance_power,  power. Это сильно напоминает cpufreq, и balance_power выглядит как аналог conservative.

Вот показания датчиков без нагрузки и снагрузкой. В комнате 27-28 ℃.

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

UPD: Если выставить в прошивке управление батареей "Let HP manage your battery health", то эта гнида будет считать за цикл зарядки, если разрядить ее до 80% и зарядить до 100. Если оставить  "maximize performance", то счетчик не будет увеличиваться, как и должно быть. В общем, надо выбирать или "battery health", или "performance", если не хочешь, чтобы батарея накрылась через месяц. Но health заряжает только до 80%, то есть если его активировать, то не надо подключать ноут к сети, если там больше 80% заряда, иначе контроллер уйдет в защиту. Кто-то держит на 80% постоянно подключенным к сети, я разряжаю до 89% и заряжаю каждый раз, а после использования отключаю. У меня телефонные аккумуляторы в таком режиме живут уже по 16 лет.

UPD2: Я решила проблему со сном, и виновата оказалась не прошивка, а пидорский elogind, который Алиен Боб притащил в систему, чтобы работало его дурацкое КДЕ. Если коротко, я сняла бит исполнения с этого куска дерьма в каталоге /etc/rc.d и закомментировала все строки с elogind в конфигах PAM. Теперь всё работает как часы, команды сна отдаю через интерфейс ядра. Кроме того, что починился suspend, исчезла пауза при авторизации пользователя в системе между вводом логина и пароля -  зря я грешила на pam.

Обновление прошивки на HP Elitebook 840 G5

 Нарыла свою старую статью о приключениях одного моего другана. На сайте HP очень распространена рекомендация обновить прошивку. Вот, почитайте, что после этого бывает.

У меня есть друг Санёк. Где-то в 2014-15 году он купил ноут фирмы HP: Elitebook 840 G5 с конфигурацией intel core i5-8250U, 4 ядра по 1.6 GHz с разгоном до 3.4 в режиме турбо. Он тогда стоил около 100 килорублей. Я помню, когда он его только купил, то рассказывал, что с выключенным turbo boost ноут не загружается. Вообще, когда я ещё сидела на винде, то много читала о том, что у HP проблемы с драйверами и прошивкой. Если у вас не винда, проблемы усугубляются, в чем Санёк убедился лично.

Собственно этот turbo boost и стал причиной всей свистопляски. Это интеловская технология: при выполнении задач, не расходующих процессор, он работает с базовой тактовой частотой, а при необходимости одно ядро разгоняется в случае Санька больше чем в 2 раза. Короче, через месяц после окончания гарантийного срока у Саниного ноута вздулась батарея. Оказалось, что он пользовался турбо, а в его старой прошивке не было "умного" управления АКБ - это когда она заряжается до 80% и разряжается до 20%. Режим турбо требует наличия батареи, так как блок питания ноутбука не рассчитан на такую мощность, и поэтому получается, что батарея постоянно слегка разряжается, потом автоматически начинает заряжаться и быстро дохнет из-за большого количества циклов зарядки. 

Купил Саня АКБ русско-китайского производства, вставил её, ноут заработал, но перед загрузкой системы прошивка каждый раз высирала сообщение о том, что "у вас левая батарея, это может повлечь ядерный взрыв и эпидемию чумы". Санька это сообщение разозлило, и он полез на форум HP. Оказалось, что там сидят дебилы типа как в ростелекоме на первой линии: им уже задали этот вопрос, и они ответили, что надо отключить уведомления в винде. Автор вопроса напомнил придуркам, что сообщение появляется до загрузки системы, после чего его просто проигнорили. Саня сказал, что они вообще если встречают вопрос, на который не могут ответить, то шлют на хуй без церемоний.

Тогда Санек решил проявить смелость и обновить прошивку. Нет, он не лох и не чайник, он системный архитектор. Просто никогда раньше не делал этого, решил попробовать (на свою ж...). Он решил делать это из Винды. У него дуалбут: искоробочная Виндос 10 и Генту. Виндой он пользуется только для игр, поэтому три года её не обновлял. Чтобы найти нужную прошивку, он обновил систему, и она затерла ему первичный загрузчик GRUB. Он признался, что у него долго горела жопа: сука, я же не устанавливал её, а только обновил! Так как он занимается этим не каждый день, ему пришлось читать документацию, как записать grub обратно, скачивать system rescue cd и все это делать. Протрахался около двух часов. Это было только начало. Но наконец все было сделано, и винда в опциональных обновлениях предложила ему обновить EFI.

После этой процедуры сообщение о батарее не исчезло, зато тачпад - Саня предпочитает его мыши - стал глючить, пролистывая две страницы вместо одной. Этот глюк проявлялся только в генту, но не в винде. Но это ещё не самое хреновое. Оказалось, что кулер на процессоре перестал разгоняться до полных оборотов. Естественно, чип стал греться как не в себя и в генту, и в винде. Саня решил откатить прошивку назад, но с версии, предшествующей его версии, откат стал невозможен. Он узнал об этом из документации на сайте HP, а не из сообщения, которое должно было его об этом предупредить перед обновлением. Кстати, он очень похвалил официальную документацию на их сайте: сказал, что там черт ногу сломает, хрен разберешься. Тогда он решил обновиться до следующей версии, которую нарыл на сайте. В общем, потрахавшись ещё, он обновился, и там, насколько я помню, как раз оказалось умное управление батареей. Ну хоть что-то.

Поимев секс, Санёк решил проблему с тачпадом, а с вентилятором ничего не вышло. Он попробовал thermald, но тот ему не помог, что в принципе логично - прошивка же не работает, что система может. В результате он просто выставил порог, выше которого частота не должна подниматься, и сидит теперь на обгрызанном процессоре.

Итак, в результате обновления прошивки Саня приобрел умное управление АКБ, которое увеличит срок службы последней, если пользоваться режимом турбо, без которого ноут не загружается. При этом у него перестал раскручиваться на полную мощность вентилятор. Сообщение о левой батарее не исчезло. Также он просрал десять дней своего времени и кучу нервов. Давать оценку результату я предоставлю читателям.