Создание сервиса linux. как создать свой сервис для linux с systemd

Настраиваем Samba

Перед непосредственно настройкой, программу нужно установить. Установка Samba выполняется таким же образом, как в случае с другими программами — при помощи ввода в терминал команды:

Сразу же заметьте: все действия, которые будут описаны, включая и установку программы, можно выполнить как на простой Ubuntu, так и на Ubuntu Server. Только на последней доступен исключительно текстовый интерфейс.

После установки следует сделать бэкап файла конфигурации:

Дальше делаем свой документ с глобальными параметрами:

Либо редактируем существующий. В этом файле содержатся основные установки сервера Самбы. Чтобы разобраться, что мы будем делать дальше, нужно понимать, что означают различные строки.

Workgroup — рабочая группа. Значение этого параметра также часто будет Workgroup, поскольку в Виндовс домен рабочей группы по умолчанию выглядит именно так.
Netbios name — имя компьютера Ubuntu, которое видят пользователи Windows. Здесь можно вводить значение на своё усмотрение.
Security — режим авторизации пользователей. По умолчанию стоит User, то есть аутентификация на уровне пользователя. Пока что лучше так и оставить.
Os level — указывает приоритет, который имеет Samba над другими клиентами (ПК) в локальной или интернет-сети.
Name resolve order — очерёдность разрешения IP-адресов по NetBIOS имени.
Read only — привилегия чтения или записи каталога. Значение может быть «yes» — исключительно чтение, «no» — запись.

Создаём пользователя

Это простейшее действие, с которого можно начинать работу с Самбой.

Добавляем пользователя в самой ОС:

Создаём для него пароль:

Занесём нашего пользователя в базу Samba:

При помощи команды $ smbpasswd можно выполнять другие различные действия:

$ smbpasswd username — смена пароля
$ smbpasswd -x username — удаление пользователя
$ smbpasswd -d username — бан пользователя

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

Это базовые настройки Samba. Теперь можно попробовать применить программу на практике.

Доступ к папке

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

Создаём папку, с которой и будем потом работать на двух компьютерах:

Теперь делаем для этой папки расширенный доступ, чтобы её мог открыть любой клиент нашей локальной сети:

Владельцем согласно коду является nobody.

Теперь в файле с конфигурацией сервера нужно сделать два раздела: первый, содержащий основную информацию:

Следуют разделы друг за другом в таком же порядке.

Обновляем изменения сервера:

Действия с компьютером на Windows

На Винде также требуется выполнить некоторые действия, чтобы можно было без труда открыть новую общую папку и редактировать её.

Открываем командную строку. Желательно делать это с расширенными правами, т. е. от имени администратора.
Выполняем команду:
notepad C:\Windows\System32\drivers\etc\hosts
Открывается файл, в котором вводим следующую строчку:
168.0.1 srvr1.domain.com srvr1 Благодаря ей папка станет доступна.
Открыть её можно при помощи строки «Выполнить». Жмём Win + R, вводим: После этого нам откроется папка.

Закрытая папка

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

Делаем папку с названием «Closed»:

Делаем специальную группу, которая может иметь доступ к этой папке:

Создаём особые права для разных групп:

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

Перезапускаем сервер.

Как можно понять, мы сделали папку Closed внутри Access. Таким образом Access может открыть каждый пользователь локальной сети, но чтобы смотреть и редактировать Closed, нужно обладать особыми правами.

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

Создаём пользователя и добавляем его в нашу закрытую группу:

Пользователя у нас зовут, как пачку сигарет (или премьер-министра Британии).

Делаем для Уинстона пароль:

После этого нам предложат ввести новый пароль, чтобы зайти заново под только что созданным аккаунтом. Не забудьте после этого сделать перезагрузку. Теперь вы знаете, как настроить сервер через Самбу в Убунту.

Конечно, возможности Samba не исчерпываются только созданием простых папок. Но эти простые инструкции и примеры показывают, что можно сделать при помощи этой программы. Это будет первым шагом к пониманию сути серверных ПК и их управления.

Основные настройки

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

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

Переменные окружения

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

Для переменной пользовательского каталога, создайте файл .conf в каталоге со строками вида {{ic | 1 = NAME = VAL}. Применяется только к части пользовательских служб.

Смотрите для получения дополнительной информации.

Используйте опцию в . Применяется ко всем пользовательским службам.
Добавление конфигурационного файла в . Применяется ко всем пользовательским процессам; см
Для временного изменения используйте или . Применяется ко всем пользовательским службам, созданным после установки переменных окружения, но не к службам, которые уже были запущены.
Используйте команда обеспечивается dbus. Имеет тот же эффект, что и , но так же влияет на сессию D-Bus. Вы можете добавить это в конец вашего файла инициализации оболочки.
Для «глобальных» переменных пользовательского окружения вы можете использовать каталоги , которые анализируются генераторами systemd. Подробнее см. и .
Вы также можете написать скрипт генератора среды, который может создавать переменные среды, которые варьируются от пользователя к пользователю. Это, вероятно, лучший способ, если вам нужны индивидуальные среды (это относится к , и т.д.). Смотрите .

Одну переменную Вы можете установить в .

После настройки можно использовать команду для проверки правильности значений.

Пример службы

Создайте каталог и внутри создайте файл с расширением (например, ):

/etc/systemd/system/user@.service.d/local.conf

Environment="PATH=/usr/lib/ccache/bin:/usr/local/bin:/usr/bin:/bin"
Environment="EDITOR=nano -c"
Environment="BROWSER=firefox"
Environment="NO_AT_BRIDGE=1"

PATH

Если изменить и запланированный запуск приложений, которые используют службу systemd, Вы должны убедиться, что модифицированный установлен и в среде systemd. Если предположить, что Вы установили переменную в , то лучшим способом сделать systemd осведомленным о модификации будет добавление в после заданной переменной:

~/.bash_profile

systemctl --user import-environment PATH

Обратите внимание, что это не повлияет на службы systemd, запущенные до импортирования PATH.

pam_environment

Переменные среды можно сделать доступными с помощью модуля . Смотрите для деталей конфигурации.

Автоматический запуск systemd от имени пользователя

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

# loginctl enable-linger username

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

Решение проблем

Неудачно запущенные службы

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

$ systemctl --state=failed

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

Диагностика службы

Если какая-либо служба systemd ведет себя не так, как ожидается, и вы хотите получить дополнительную информацию о том, что происходит, присвойте переменной окружения значение . Например, чтобы запустить демон systemd-networkd в режиме отладки:

Добавьте для службы:

Environment=SYSTEMD_LOG_LEVEL=debug

Или, как вариант, пропишите переменную окружения вручную:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

После этого systemd-networkd и следите за журналом службы с помощью опции /.

Время загрузки системы увеличивается с течением времени

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

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

systemd-tmpfiles-setup.service не запускается во время загрузки

Начиная с версии Systemd 219, определяет ACL-атрибуты для каталогов в и, следовательно, требует поддержки ACL для той файловой системы, в которой находится журнал.

Отключение emergency mode на удалённой машине

Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.

Для отключения этого режима и .

Советы и рекомендации

Программы настройки с графическим интерфейсом

systemadm — Графический поисковик юнитов systemd. Выводит список юнитов, возможна фильтрация по типу.

SystemdGenie — Утилита управления systemd на основе инструментов KDE.

Запуск сервисов после подключения к сети

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

/etc/systemd/system/foo.service

...
Wants=network-online.target
After=network-online.target
...

Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда будет соответствовать состоянию сети.

В NetworkManager служба включается вместе с . Проверить состояние службы можно командой . Если служба не включена, то ещё раз.
В случае netctl службу .
Для пользователей systemd-networkd юнит включается вместе со службой ; проверьте это командой . Если нет, то .

Если служба отправляет DNS-запросы, она должна запускаться также после :

/etc/systemd/system/foo.service

...
Wants=network-online.target
After=network-online.target nss-lookup.target
...

Подробнее см. .

Чтобы цель работала как положено, должна быть служба, которая запускает её параметром и размещает себя перед ней (). Обычно это выполняет локальный .

Чтобы узнать, какие службы зависят от , выполните:

$ systemctl list-dependencies --reverse nss-lookup.target

Включение установленных юнитов по умолчанию

This article or section needs expansion.

Arch Linux поставляется с файлом , в котором указан параметр . Это означает, что systemctl preset отключает по умолчанию юниты и пользователь должен сам их включать после установки пакетов.

Если такое поведение не устраивает, создайте символическую ссылку на для переопределения файла конфигурации. Это заставит systemctl preset включать юниты новых пакетов — вне зависимости от типа — кроме указанных в других файлах из каталога настроек systemctl preset. Пользовательских юнитов это не касается. Подробнее смотрите .

Примечание: Политика включения всех юнитов по умолчанию может привести к проблемам, если в установленном пакете находится несколько взаимоисключающих юнитов. В этом случае в файле preset-настроек придётся явно указать, какие юниты включаться не должны. Подробнее смотрите .

Песочница для приложений

Юнит может быть использован в качестве песочницы для изоляции приложений и их процессов в виртуальном окружении. Systemd использует механизм namespaces, белые и чёрные списки capabilities, а также control groups для контейнеризации процессов при помощи настраиваемых окружений — см. .

Добавление к существующему юниту systemd функциональности песочницы обычно происходит методом проб и ошибок вкупе с использованием различных инструментов логирования — , и . В таких случаях имеет смысл предварительно поискать соответствующую документацию от разработчиков. В качестве отправной точки для поиска путей повышения безопасности изучите вывод команды:

$ systemd-analyze security юнит

Рекомендации по созданию песочницы с помощью systemd:

Параметр определяет список разрешённых capabilities, но с его помощью можно также и запрещать некоторые capabilities для определённого юнита.

Уведомление о неработающих службах

Для уведомления о неудачном запуске службы используется директива в соответствующем файле службы или . Чтобы эта директива возымела эффект для всех служб одновременно, её необходимо добавть в drop-in файл верхнего уровня, см. .

Создайте drop-in верхнего уровня:

/etc/systemd/system/service.d/toplevel-override.conf

OnFailure=failure-notification@%n

Это добавит строку в файл каждой службы. Если какой-то_юнит завершится с ошибкой, запустится экземпляр службы для создания уведомления (или любой другой задачи, которая была назначена).

Создайте юнит-шаблон :

/etc/systemd/system/failure-notification@.service

Description=Send a notification about a failed systemd unit
After=network.target


Type=simple
ExecStart=/путь/к/failure-notification.sh %i

После этого создайте сценарий , в котором определите, каким именно способом будет создаваться уведомление (mail, gotify, xmpp). Параметр будет заменён на название неудачно завершившегося юнита и будет передан сценарию в качестве аргумента.

Чтобы предотвратить регрессию экземпляров , создайте пустой файл drop-in настроек с именем, совпадающим с названием drop-in файла верхнего уровня (пустой файл «уровня служб» будет иметь приоритет над файлом «верхнего уровня»):

# mkdir -p /etc/systemd/system/failure-notification@.service.d
# touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

Завершение процессов пользователя при выходе из системы

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

Обратите внимание, что изменение этого параметра нарушает работу мультиплексоров терминала, таких как tmux и GNU Screen (Русский). Если вы измените этот параметр, вы все равно сможете использовать терминальный мультиплексор, используя следующим образом:

$ systemd-run --scope --user command args

Например, чтобы запустить , вы должны сделать:

$ systemd-run --scope --user screen -S foo

Запущенные с помощью процессы продолжат работу даже после выхода пользователя, если он залогинен в системе где-то ещё и служба всё ещё работает.

Подключение к шаре

Теперь разберем примеры подключения к нашим шарам из разных систем.

Windows

Для разового подключения можно использовать проводник, прописав в нем адрес сервера через косые линии:

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

В открывшемся окне прописываем путь до сетевой папки и выбираем имя диска:

Сетевой диск настроен.

Но мы может сделать те же действия из командной строки:

net use x: \\samba.dmosk.local\AD ACL /persistent:yes

* где x: — имя сетевого диска; \\samba.dmosk.local\AD ACL — путь до сетевого каталога; persistent:yes — указывает на то, что нужно восстанавливать данный диск каждый раз при входе в систему.

Монтирование

В Linux мы можем монтировать удаленный каталог с помощью команды mount, например:

mount -t cifs «//192.168.1.15/ad» /mnt -o user=dmosk

* где 192.168.1.15 — IP-адрес сервера; mnt — каталог, куда монтируем сетевую шару; dmosk — пользователь, под которым выполняем подключение к сетевому каталогу.
** в систему должен быть установлен пакет cifs-utils.

Подробнее, процесс монтирования описан в инструкции Как в Linux монтировать шару CIFS.

SMB Browser

Также мы можем увидеть содержимое удаленных папок на samba при помощи клиента smb. Для начала установим данного клиента:

а) на Red Hat / CentOS / Fedora:

yum install samba-client

б) на Debian / Ubuntu / Mint:

apt-get install samba-client

После вводим команду:

smbclient -L 192.168.1.15 -U staff@dmosk.local

* где 192.168.1.15 — сервер samba, к которому мы пытаемся подключиться; staff@dmosk.local — учетная запись, под которой выполняется подключение.

… мы получим список каталогов, которые расшарены на сервере.

Также мы можем подключиться к конкретной папке, например:

smbclient \\\\192.168.1.15\\ad -U staff@dmosk.local

Мы подключимся клиентом samba — можно выполнить запрос на показ содержимого:

smb: \> ls

Или полный список возможных команд:

smb: \> help

Установка и запуск Samba

Установка выполняется из репозитория одной командой:

dnf install samba

Разрешаем автостарт сервиса и запускаем его:

systemctl enable smb —now

И проверим, что сервис запустился:

systemctl status smb

Проверяем, что сервер самба позволяет к себе подключиться. Для этого можно с компьютера обратиться к серверу по SMB, например, на компьютере с Windows это можно сделать из проводника, прописав путь к серверу с двух слэшей:

* в данном примере мы подключаемся к серверу Samba с IP-адресом 192.168.1.15.

Если мы настроили сервер правильно, система должна запросить пароль на подключение к Samba. Отказываемся его вводить. На данном этапе проверка закончена.

Редактирование прав

Все, что нужно для разрешения проблем, связанных с правами в Linux.

sudo — выдает права суперпользователя. Используется перед любой командой, если нужно выполнить ее от имени администратора. Многие программы и операции запускаются исключительно при наличии этих прав, так что sudo используется часто. Например, чтобы обновить список пакетов в Fedora, введем: sudo dnf update. При этом система запросит пароль администратора.

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

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

chmod — корректирует права доступа к выбранному файлу. Применяется исключительно с набором опций, обозначающих список прав. Допустим, я хочу выдать права на чтение и запись файла Timeweb.html на рабочем столе. Для этого введу в терминал: chmod 777 ~/Desktop/timeweb.html. Теперь его можно открывать и редактировать. Аналогичным образом пользователи поступают с системными файлами, когда приходит время что-то в них менять. По умолчанию большая их часть защищена от записи.

chown — назначает владельца для выбранной директории, документа, картинки или любого другого элемента в файловой системе. Синтаксис следующий: chown имя учетной записи, которому надо передать права путь до файла, права на который нужно передать. На примере этого может выглядеть следующим образом: есть пользователь Timeweb, которому я хочу передать права на файл timeweb-file.txt с рабочего стола. Сделаю это командой:

chown Timeweb ~/Desktop/timeweb-file.txt

Некоторые случаи использования

Постоянный терминальный мультиплексор

This article or section is out of date.

Возможно, вы захотите, чтобы в сеансе пользователя по умолчанию использовался терминальный мультиплексор, например GNU Screen или Tmux, в фоновом режиме, а не для входа в сеанс оконного менеджера. Разделение входа в систему от входа в систему X, скорее всего, полезно только для тех, кто загружается с TTY, а не с экранным менеджером (в этом случае вы можете просто связать все, что вы запускаете, с myStuff.target).

Чтобы создать пользовательский сеанс такого типа, действуйте, как указано выше, но вместо создания wm.target создайте multiplexer.target:

Description=Terminal multiplexer
Documentation=info:screen man:screen(1) man:tmux(1)
After=cruft.target
Wants=cruft.target


Alias=default.target

, как выше, должен запускать все, что, по вашему мнению, должно запускаться до запуска tmux или экрана (или что вы хотите запустить при загрузке независимо от времени), например сеанс демона GnuPG.

Затем вам нужно создать сервис для сеанса мультиплексора. Вот пример службы, использующей tmux в качестве примера и использующей сеанс gpg-agent, который записал свою информацию в . Этот пример сеанса при запуске X также сможет запускать программы X, так как установлен DISPLAY.

Description=tmux: A terminal multiplixer 
Documentation=man:tmux(1)
After=gpg-agent.service
Wants=gpg-agent.service


Type=forking
ExecStart=/usr/bin/tmux start
ExecStop=/usr/bin/tmux kill-server
Environment=DISPLAY=:0
EnvironmentFile=/tmp/gpg-agent-info


WantedBy=multiplexer.target

Как только это будет сделано, , и любые сервисы, которые вы создали для запуска , и вы должны быть готовы к работе! Активирован , как описано выше, но обязательно удалите из {{ic|user-session@.service} }, поскольку ваш пользовательский сеанс не будет принимать TTY. Поздравляем! У вас есть работающий терминальный мультиплексор и некоторые другие полезные программы, готовые к запуску при загрузке!

Оконный менеджер

Чтобы запустить оконный менеджер в качестве службы systemd, сначала необходимо запустить . В следующем примере мы будем использовать awesome (Русский):

~/.config/systemd/user/awesome.service

Description=Awesome window manager
After=xorg.target
Requires=xorg.target


ExecStart=/usr/bin/awesome
Restart=always
RestartSec=10
 

WantedBy=wm.target

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

Подготовка сервера

1. Время

Для корректного отображения дат, необходимо позаботиться о синхронизации времени. Для этого будем использовать демон chrony. Установим его:

dnf install chrony

Разрешим автозапуск и стартанем сервис:

systemctl enable chronyd

systemctl start chronyd

2. Брандмауэр

По умолчанию, в системах CentOS брандмауэр (firewalld) запрещает все соединения. Необходимо разрешить сервис samba. Также в нашей системе может использоваться система управления брандмауэром iptables. Рассмотрим оба варианта.

а) Если используется firewalld.

Выполняем команду:

firewall-cmd —permanent —add-service=samba

Применяем настройки:

firewall-cmd —reload

б) Если используется iptables.

По умолчанию, iptables разрешает все соединения. Но если в нашем случае мы настроили брандмауэр на запрет пакетов, необходимо открыть порты:

iptables -I INPUT -p tcp —dport 445 -j ACCEPT

iptables -I INPUT -p udp —dport 137:138 -j ACCEPT

iptables -I INPUT -p tcp —dport 139 -j ACCEPT

* где порт 445 используется для samba, а порты 137, 138 и 139 — для работы NetBIOS (использование имени компьютера для доступа).

Применяем настройки:

service iptables save

3. SELinux

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

dnf install policycoreutils setroubleshoot

Теперь создаем само правило. Например, если мы планируем использовать каталог /data, то вводим команды:

mkdir /data

* на случай, если каталога еще нет, создаем его.

semanage fcontext -a -t samba_share_t «/data(/.*)?»

restorecon -R -v /data

Или можно просто отключить SELinux.

Troubleshooting

Investigating failed services

To find the systemd services which failed to start:

$ systemctl --state=failed

To find out why they failed, examine their log output. See for details.

Diagnosing a service

If some systemd service misbehaves or you want to get more information about what is happening, set the environment variable to . For example, to run the systemd-networkd daemon in debug mode:

Add a for the service adding the two lines:

Environment=SYSTEMD_LOG_LEVEL=debug

Or equivalently, set the environment variable manually:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

then restart systemd-networkd and watch the journal for the service with the / option.

Shutdown/reboot takes terribly long

A common problem is a stalled shutdown or suspend process. To verify if it is the case you could run either of these commands and check the outputs

# systemctl poweroff

Failed to power off system via logind: There's already a shutdown or sleep operation in progress

# systemctl list-jobs

JOB UNIT                    TYPE  STATE  
...
21593 systemd-suspend.service start running
21592 suspend.target          start waiting
..

# systemctl cancel
# systemctl stop systemd-suspend.service

and then trying shutdown or reboot again.

Boot time increasing over time

The factual accuracy of this article or section is disputed.

After using a number of users have noticed that their boot time has increased significantly in comparison with what it used to be. After using NetworkManager is being reported as taking an unusually large amount of time to start.

The problem for some users has been due to becoming too large. This may have other impacts on performance, such as for or . As such the solution is to remove every file within the folder (ideally making a backup of it somewhere, at least temporarily) and then setting a journal file size limit as described in .

systemd-tmpfiles-setup.service fails to start at boot

Starting with systemd 219, specifies ACL attributes for directories under and, therefore, requires ACL support to be enabled for the filesystem the journal resides on.

See for instructions on how to enable ACL on the filesystem that houses .

Disable emergency mode on remote machine

You may want to disable emergency mode on a remote machine, for example, a virtual machine hosted at Azure or Google Cloud. It is because if emergency mode is triggered, the machine will be blocked from connecting to network.

To disable it, and .

Решение проблем

Runtime directory ‘/run/user/1000’ is not owned by UID 1000, as it should

systemd: pam_systemd(systemd-user:session): Runtime directory '/run/user/1000' is not owned by UID 1000, as it should.
systemd: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set

Если вы видите такую ошибку и ваш сеанс в порядке, то возможно, что другая системная (не пользовательская) служба создала этот каталог. Например, такое могло произойти при использовании контейнера docker, который выполнил bind-монтирование в каталог . Чтобы это исправить, либо отредактируйте контейнер, удалив монтирование, либо отключите/отложите службу docker.