Как отключить systemd-resolve в linux

Шпаргалка по часто используемым командам systemctl

1. Посмотреть статус службы:

# systemctl status network

* покажет статус службы на примере сети network

2. Запустить сервис:

# systemctl start mysql

* запустит сервис баз данных на примере mysql

3. Остановить службу:

# systemctl stop ntpd

* остановит сервис времени ntpd

4. Перезапустить службу:

# systemctl restart nginx

* перезапустит веб-сервер nginx

5. Включить автозапуск службы:

# systemctl enable apache

* разрешит автозапуск веб-сервера apache

6. Отключить автозапуск службы:

# systemctl disable firewalld

* запретит автозапуск брандмауэра firewalld

7. Выполнить команду на удаленной системе:

systemctl —host root@192.168.0.15 stop cron

* остановит cron на компьютере с IP-адресом 192.168.0.15, подключившись под учетной записью root.

8. Перезагрузить сервер:

systemctl reboot

* перезагрузит локальный сервер.

Videos for Users and Administrators

• Presentation about kdbus at linux.conf.au 2014
• Presentation about systemd at the Red Hat Summit 2013
• Presentation about the journal at Devconf 2013
• Presentation about recent developments at Devconf 2013
• Presentation about systemd at FOSDEM 2013 (Audio is bad 0:29 — 06:12, please seek ahead), (Slides)
• Presentation about systemd at FOSS.in 2012
• Presentation about systemd at OSEC Barcamp 2012
• Presentation about systemd at FOSDEM 2011
• Presentation about systemd at linux.conf.au 2011, (Slides)
• Interview about systemd at golem.de (German)
• Presentation about systemd at OSworld 2014 (systemd cheat-sheet) (Polish)

Targets

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

systemd uses targets to group units together via dependencies and as standardized synchronization points. They serve a similar purpose as runlevels but act a little differently. Each target is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some targets are implemented by inheriting all of the services of another target and adding additional services to it. There are systemd targets that mimic the common SystemVinit runlevels so you can still switch targets using the familiar command.

The following should be used under systemd instead of running :

$ systemctl list-units --type=target

Create custom target

The runlevels that held a defined meaning under sysvinit (i.e., 0, 1, 3, 5, and 6); have a 1:1 mapping with a specific systemd target. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd target as that takes one of the existing runlevels as a base (you can look at as an example), make a directory , and then symlink the additional services from that you wish to enable.

Mapping between SysV runlevels and systemd targets

SysV Runlevel	systemd Target	Notes
runlevel0.target, poweroff.target	Halt the system.
1, s, single	runlevel1.target, rescue.target	Single user mode.
2, 4	runlevel2.target, runlevel4.target, multi-user.target	User-defined/Site-specific runlevels. By default, identical to 3.
3	runlevel3.target, multi-user.target	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5	runlevel5.target, graphical.target	Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.
6	runlevel6.target, reboot.target	Reboot
emergency	emergency.target	Emergency shell

Change current target

In systemd targets are exposed via target units. You can change them like this:

# systemctl isolate graphical.target

This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as or in Sysvinit.

Change default target to boot into

The standard target is , which is a symlink to . This roughly corresponds to the old runlevel 5.

To verify the current target with systemctl:

$ systemctl get-default

To change the default target to boot into, change the symlink. With systemctl:

# systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Alternatively, append one of the following kernel parameters to your bootloader:

• (which roughly corresponds to the old runlevel 3),
• (which roughly corresponds to the old runlevel 1).

What is this?

is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution. See the introductory blog story and three status updates for a longer introduction. Also see the Wikipedia article.

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

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

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

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

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

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

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

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

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

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

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

/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. Не используйте долговременные службы для включения автоматического входа в систему, иначе будет .

The systemd for Administrators Blog Series

• #1: Verifying Bootup
• #2: Which Service Owns Which Processes?
• #3: How Do I Convert A SysV Init Script Into A systemd Service File?
• #4: Killing Services
• #5: The Three Levels of «Off»
• #6: Changing Roots
• #7: The Blame Game
• #8: The New Configuration Files
• #9: On /etc/sysconfig and /etc/default
• #10: Instantiated Services
• #11: Converting inetd Services
• #12: Securing Your Services
• #13: Log and Service Status
• #14: The Self-Explanatory Boot
• #15: Watchdogs
• #16: Gettys on Serial Consoles (and Elsewhere)
• #17: Using the Journal
• #18: Managing Resources
• #19: Detecting Virtualization
• #20: Socket Activated Internet Services and OS Containers
• #21: Container Integration

Also available: a Russian translation;
another, more complete Russian translation as PDF;

Основы использования systemctl

Главная команда для отслеживания и контроля состояния systemd — команда systemctl. Некоторые из вариантов ее использования связаны с изучением состояния системы и управлением системой и службами. Обратитесь к странце руководства для получения более детальной информации.

Совет:

Вы можете использовать все приведенные ниже команды systemctl с ключом -H пользователь@хост для того, чтобы контролировать systemd на удаленной машине. В этом случае для соединения с удаленным процессом systemd будет использоваться SSH

Совет:

systemadm — официальная графическая оболочка для systemctl. Она доступна в пакетах systemd-ui и systemd-ui-gitAUR

Анализ состояния системы

Список запущенных юнитов:

$ systemctl

или:

$ systemctl list-units

Список неудач, — список юнитов, попытка запуска которых не удалась:

$ systemctl --failed

Доступные файлы юнитов можно посмотреть в директориях и (второй каталог имеет приоритет). Вы можете увидеть список установленных файлов юнитов командой:

$ systemctl list-unit-files

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

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

• Ели вы не указали суффикс, systemctl предполагает, что это .service. Например, и будут трактоваться одинаково
• Точки монтирования будут автоматически преобразованы в соответствующий юнит .mount. Например, указание равнозначно
• Так же, как и точки монтирования, имена устройств автоматически преобразуются в соответствующий юнит .device, поэтому указание полностью соответствует юниту

Для получения дополнительной информации смотрите страницу справочного руководства .

Совет:

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

Незамедлительно запустить юнит:

# systemctl start юнит

Незамедлительно остановить юнит:

# systemctl stop юнит

Перезапустить юнит:

# systemctl restart юнит

Запросить у юнита перезагрузку его настроек:

# systemctl reload юнит

Показать статус юнита, а также запущен он или нет:

$ systemctl status юнит

$ systemctl is-enabled юнит

# systemctl enable юнит

# systemctl disable юнит

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

# systemctl mask юнит 

Снять маску юнита:

# systemctl unmask юнит 

Показать страницу справочного руководства, связанного с юнитом (необходима поддержка этой функции в указанном файле юнита):

$ systemctl help юнит

Перезагрузить systemd для поиска новых или измененных юнитов:

# systemctl daemon-reload

Управление питанием

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальной пользовательской сессии systemd-logind, и нет других активных сессий, приведенные ниже команды сработают и без привилегий суперпользователя. В противном случае (например, вследствие того, что другой пользователь вошел в систему в tty), systemd автоматически запросит у вас пароль суперпользователя.

Завершить работу и перезагрузить систему:

$ systemctl reboot

Завершить работу и выключить компьютер (с отключением питания):

$ systemctl poweroff

Перевести систему в ждущий режим:

$ systemctl suspend

Перевести систему в спящий режим:

$ systemctl hibernate

Перевести систему в режим гибридного сна (или suspend-to-both):

$ systemctl hybrid-sleep

Основы

Если ты еще никогда не делал свои сервисы, начнем с основ. Systemd оперирует абстрактными единицами (unit), которые бывают разных типов, могут предоставлять различные ресурсы (процессы, сокеты, абстрактные «цели») и требовать других ресурсов для запуска.

Самый распространенный вид ресурса — сервис (service). Файлы с описаниями сервисов и всего прочего лежат в каталоге . Чтобы systemd нашел новый сервис, достаточно положить в этот каталог свой файл. Если этот сервис ранее не существовал, systemd прочитает файл и загрузит его в память. Однако, если ты редактируешь файл ранее запущенного сервиса, не забудь заставить systemd перечитать файлы командой !

Сервисы типа oneshot — долой rc.local

Когда-то стандартным способом добавить выполнение команд в загрузку системы было дописать их в /etc/rc.local. Очевидный недостаток — нет способов следить, насколько успешно они выполнились. В systemd легко создать для такой цели свой сервис типа oneshot, и им можно будет управлять через systemctl, как любым другим. В этом случае systemd выполнит команду и посчитает запуск сервиса успешным, если она завершилась с кодом ноль.

Сохраним следующий файл в :

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

Делаем сервис из любой программы

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

Для демонстрации напишем программу на Python, которая просто выводит сообщение в бесконечном цикле. Сохраним в следующее:

Затем создадим для нее файл сервиса в :

Теперь можно запустить наш сервис и убедиться, что он работает:

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

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.

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.

# systemctl mask emergency.service
# systemctl mask emergency.target