Linux запуск службы с правами пользователя

Как заставить мою службу systemd запускаться через определенного пользователя и запускать при загрузке?

Я только что обновился с сервера Ubuntu 14 до версии 15. У меня возникли проблемы с запуском скрипта выскочки после обновления и прочитал, что systemd является новым значением по умолчанию. Я далек от эксперта по Linux, поэтому, пожалуйста, пройдите на меня: -)

Вот что мой скрипт upstart был раньше:

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

Этот файл находится в /home/robert/.config/systemd/user/nzbget.service . Чтобы запустить службу вручную, я выполнял:

Это отлично работает. Однако, когда я выхожу из сеанса SSH, служба отключается. Кроме того, он не запускается при загрузке или входе в систему. Я хочу, чтобы он вел себя так же, как и в качестве услуги upstart: я хочу, чтобы он запускался при загрузке, запускался постоянно и как конкретный пользователь.

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

2 ответа

Первая проблема

Вы можете указать директивы User= и Group= в разделе [Service] файла устройства.

Вторая проблема

Чтобы запустить службу при загрузке, вы не должны помещать ее в свою домашнюю папку. Вместо этого поставьте его под /etc/systemd/system/ . Это папка, предназначенная для использования системным администратором (т. Е. Вы) для добавления новых общесистемных служб.

• /usr/lib/systemd/system/ предназначен для пакетов, которые хотят установить единичные файлы, хотя в Debian и Ubuntu на самом деле папка /lib/systemd/system/ потому что различные папки bin и lib еще не объединены в унифицированный префикс /usr/ .
• /usr/local/systemd/system/ предназначен для установки модулей локально скомпилированными пакетами.

Тестирование устройства

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

Включение устройства

Прежде чем вы сможете включить свой блок, вам нужно добавить раздел [Install] , под которым вы должны добавить директиву WantedBy=multi-user.target . Эта директива определяет этап процесса загрузки, во время которого должна запускаться служба (если она была включена). multi-user.target подходит для большинства служб.

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

Вам может быть интересно использовать функциональные возможности systemd для пользователя. Он включен с помощью loginctl enable-linger USERNAME .

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

/.config/systemd/user будут отобраны и обработаны при загрузке и завершении работы в зависимости от конфигурации вашего сервиса.

Вы также можете использовать systemctl —user для управления и настройки служб (сервисов), которые будут работать в диспетчере служб вашего пользователя, а не в системе.

Источник

Управление сервисами в Linux. Команда systemctl

Что такое сервисы в Linux

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

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

Чаще всего в Linux дистрибутивах для инициализации сервисов используется демон Systemd. К Systemd-дистрибутивам относятся Ubuntu, Debian, Linux Mint, Fedora, openSUSE, Solus и другие.

Есть дистрибутивы, которые не используют Systemd. Вместо Systemd могут использоваться такие системы инициализации, как Upstart, SysV.

В качестве примеров сервисов можно привести: веб-сервер Apache, Network Manager, файрвол Ufw и другие.

Для управления сервисами (Systemd) используется утилита systemctl . Ниже мы рассмотрим основные команды данной утилиты.

Список сервисов

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

Данная команда пробегает по алфавитному списку всех доступных сервисов и выполняет для них команду status.

В выводе команды используются следующие обозначения:

• [ + ] — запущенный сервис.
• [ — ] — остановленный сервис.
• [ ? ] — для данного сервиса отсутствует команда status.

Запуск сервиса

Для запуска сервиса используется команда systemctl start имя_сервиса

Останов сервиса

Для остановки сервиса используется команда systemctl stop имя_сервиса

Перезапуск сервиса

Перезапуск сервиса выполняется командой systemctl restart имя_сервиса

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

Некоторые сервисы поддерживают «мягкую» перезагрузку. В этом случае сервис считывает связанные с ним файлы конфигурации, но не прерывает процесс сервиса. Для выполнения «мягкой» перезагрузки используется команда systemctl reload имя_сервиса . Не все сервисы поддерживают «мягкую» перезагрузку. Если она не поддерживается, то появится сообщение вида: Failed to reload ufw.service: Job type reload is not applicable for unit ufw.service.

Автозагрузка сервисов

Чтобы сервис стартовал (загружался) при запуске системы, его нужно включить в список автозагрузки. Для этого используется команда systemctl enable имя_сервиса

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

Чтобы удалить сервис из автозагрузки, используется команда systemctl disable имя_сервиса

Статус сервиса

Для вывода информации (статуса) сервиса используется команда systemctl status имя_сервиса

Чтобы проверить, запущен ли в данный момент сервис, используется команда systemctl is-active имя_сервиса

Чтобы проверить, включен ли сервис для автозапуска при загрузке системы, используется команда systemctl is-enabled имя_сервиса

Заключение

Мы рассмотрели наиболее часто используемые команды утилиты systemctl. Полный список команд и опций утилиты systemctl можно получить, выполнив:

Источник

linux-notes.org

Запустить команду от другого пользователя в Unix/Linux

Иногда, просто необходимо запустить команду от другого пользователя. И существует несколько способов, как это можно сделать. Я расскажу о них в своей статья «Запустить команду от другого пользователя в Unix/Linux».

Запустить команду от другого пользователя в Unix/Linux — способ 1

И так, можно использовать утилиту SUDO. Рассмотрим пример:

• -H YOUR_HOME: Задает HOME (Переменное окружение для хома конкретного юзера) и по умолчанию — это root.
• -u YOUR_USER: Задаем пользователя от которого будет выполнена команда.
• -c YOUR_COMMAND: Служит опцией для ввода команды.

Запустить команду от другого пользователя в Unix/Linux — способ 2

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

Логин в root юзера

Чтобы получить рута, выполните:

Запустить команду как root юзер

Вот пример команды:

Выполнить команду от другого пользователя с помощью su

И так, вот пример:

Рассмотрим другой пример:

• — — Будет имитировать логин указанного пользователя.
• -c — Служит для указания команды для выполнения (для указанного юзверя).

Запустить команду от другого пользователя в Unix/Linux — способ 3

И так, можно использовать утилиту runuser. Команда runuser запускает оболочку с заменяющими идентификаторами пользователей и групп. Эта команда полезна только когда вы залогинены как пользователь root. Синтаксис выглядит следующим образом:

Как пример, я покажу следующую строку:

PS: Для использования команды runuser пароль не требуется, и он должен запускаться только пользователем root.

• -l: Создаст оболочку для входа в систему, используя файл runuser-l PAM вместо стандартного.
• -g: Указывает на основную группу.
• -G: Указывает на дополнительную группу.
• -c: Собственно, служит для указания команды.
• –session-command=COMMAND: Передает одну команду в оболочку с опцией «-c» и не создает новый сеанс.
• -m: Не сбрасывайте переменные среды (ENV).

Вот и все, тема «Запустить команду от другого пользователя в Unix/Linux» завершена.

5 thoughts on “ Запустить команду от другого пользователя в Unix/Linux ”

> $ sudo -H -u Your_another_user bash -c ‘ping linux-notes.org’

Смешались sudo и bash:

$ sudo -u user echo a
a

$ bash -c ‘echo a’
a

Да, уже поправил. Моя опечатки. Спасибо)

su asterisk -c «xxx»
This account is currently not available.

У меня вот проблема. Надо, чтобы звук из одной сессии (x2go)
Было слышно в другой сессии. Наверное даже не так.
Некоторые программы запускаются при загрузке ПК от user1.
Когда входишь через x2go тем же user1 звук (сигнализация) от этих демонов не слышно. Всю башку сломал. Подскажите пож как решить.

sudo -u www-data pwd

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

systemd (Русский)/User (Русский)

systemd позволяет пользователю управлять службами в личном, отдельном экземпляре systemd. Благодаря этому пользователь может запускать, останавливать, включать и отключать свои собственные юниты. Это очень удобно в случае демонов и служб, которые обычно запускаются для отдельного пользователя (mpd), или выполнения автоматизированных задач (например, скачивание почты).

Contents

Как это работает

В соответствии с конфигурацией по умолчанию в /etc/pam.d/system-login , модуль pam_systemd автоматически запускает systemd —user в случае, когда пользователь в первый раз входит в систему . Этот процесс будет работать до тех пор, пока существует сессия этого пользователя, и будет убит, как только последний сеанс для пользователя будет закрыт. Когда включен #Автоматический запуск systemd от имени пользователя, то процесс запускается при загрузке и убит не будет. Пользовательский процесс systemd отвечает за управление службами пользователей, которые могут быть использованы для запуска демонов или автоматизированных задач, со всеми преимуществами systemd, таких как активация сокета, таймеры, системы зависимостей или строгий контроль процесса через контрольные группы.

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

/usr/lib/systemd/user/ где находятся службы, относящиеся к установленным пакетам.

/.local/share/systemd/user/ где находятся службы, относящиеся к пакетам, установленным в домашний каталог.
/etc/systemd/user/ где находятся общесистемные пользовательские службы, созданные системным администратором.

/.config/systemd/user/ где пользователь размещает свои собственные службы.

При запуске пользовательского процесса systemd он привязывается к пользовательской же (то есть отдельной для каждого пользователя) цели default.target . Другие службы могут управляться вручную с помощью команды systemctl —user . См. systemd.special(7) § UNITS MANAGED BY THE USER SERVICE MANAGER .

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

Все пользовательские службы размещаются в

/.config/systemd/user/ . Если вы хотите запускать службы при первом входе в систему, выполните systemctl —user enable service для любой службы, которую вы хотите сделать автозагрузочной.

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

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

Для переменной $HOME пользовательского каталога, создайте файл .conf в каталоге

/.config/environment.d/ со строками вида <. Применяется только к части пользовательских служб.

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

1. Используйте опцию DefaultEnvironment в /etc/systemd/user.conf . Применяется ко всем пользовательским службам.
2. Добавление конфигурационного файла в /etc/systemd/system/user@.service.d/ . Применяется ко всем пользовательским процессам; см #Пример службы
3. Для временного изменения используйте systemctl —user set-environment или systemctl —user import-environment . Применяется ко всем пользовательским службам, созданным после установки переменных окружения, но не к службам, которые уже были запущены.
4. Используйте dbus-update-activation-environment —systemd —all команда обеспечивается dbus. Имеет тот же эффект, что и systemctl —user import-environment , но так же влияет на сессию D-Bus. Вы можете добавить это в конец вашего файла инициализации оболочки.
5. Для «глобальных» переменных пользовательского окружения вы можете использовать каталоги environment.d , которые анализируются генераторами systemd. Подробнее см. environment.d(5) и systemd.generator(7) .
6. Вы также можете написать скрипт генератора среды, который может создавать переменные среды, которые варьируются от пользователя к пользователю. Это, вероятно, лучший способ, если вам нужны индивидуальные среды (это относится к XDG_RUNTIME_DIR , DBUS_SESSION_BUS_ADDRESS и т.д.). Смотрите systemd.environment-generator(7) .

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

После настройки можно использовать команду systemctl —user show-environment для проверки правильности значений.

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

Создайте drop-in каталог /etc/systemd/system/user@.service.d/ и внутри создайте файл с расширением .conf (например, local.conf ):

DISPLAY и XAUTHORITY

Переменная DISPLAY используется любым графическим приложением, чтобы знать, какой дисплей использовать, XAUTHORITY , чтобы указать путь к пользовательскому файлу .Xauthority , а также куки, необходимые для запуска Х-сервера. Если Вы планируете запускать графические приложения из процесса systemd, то эти переменные обязательно должны быть установлены. Systemd предоставляет скрипт в /etc/X11/xinit/xinitrc.d/50-systemd-user.sh для импорта этих переменных в пользовательскую сессию systemd на запуск X. [3] Так что если Вы не запускаете Х нестандартным образом, пользовательские службы должны знать переменные DISPLAY и XAUTHORITY .

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

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

pam_environment

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

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

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

Написание пользовательских юнитов

Смотрите systemd#Writing unit files для получения общей информации о написании юнитов модулей systemd.

Пример

Ниже приведен пример варианта пользовательской службы mpd.

Пример с переменными

Ниже приведен пример пользовательской версии sickbeard.service , которая учитывает все переменные окружения пользовательских каталогов, где SickBeard может найти некоторые файлы:

Как указано в systemd.unit(5) , переменная %h заменяется домашней директорией пользователя, запускающего службу. Есть и другие переменные, которые учитываются на странице руководства systemd.

Чтение журнала

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

Чтобы указать юнит, можно использовать

Обратите внимание, что journald не будет писать пользовательские журналы для пользователей с UID ниже 1000, вместо этого перенаправляя всё в системный журнал.

Временные файлы

systemd-tmpfiles позволяет пользователям управлять нестабильными и временными файлами и каталогами так же, как общесистемным способом (см. systemd#systemd-tmpfiles — временные файлы). Пользовательские файлы конфигурации считываются из

/.local/share/user-tmpfiles.d/ в указанном порядке. Для использования этой функциональности требуется включить необходимые пользовательские юниты systemd для вашего пользователя:

Синтаксис конфигурационных файлов такой же, как и для всей системы. Для получения дополнительной информации смотрите справочные страницы systemd-tmpfiles(8) и tmpfiles.d(5) .

Xorg и systemd

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

Автоматический логин в Xorg без экранного менеджера

The factual accuracy of this article or section is disputed.

Эта опция запускает системный блок, который запускает сеанс пользователя с сервером xorg, а затем запускает обычный

/.xinitrc для запуска оконного менеджера и т.д.

Вам необходим установленный xlogin-git AUR . Настройте свой xinitrc, как указано в разделе Xinit#xinitrc.

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

Xorg как пользовательская служба systemd

Кроме того, Xorg можно запустить из службы пользователя systemd. Это хорошо, поскольку другие связанные с X юниты могут зависеть от xorg и т. д. Но с другой стороны, у этого есть некоторые недостатки, объясненные ниже.

xorg-server обеспечивает интеграцию с systemd двумя способами:

• Может быть запущен непривилегированным, делегируя управление устройствами logind (смотрите коммиты Hans de Goede коммит).
• Может быть превращен в сервис, активируемый сокетом (смотрите этот коммит). Это устраняет необходимость в systemd-xorg-launch-helper-gitAUR .

К сожалению, чтобы иметь возможность запускать xorg в непривилегированном режиме, он должен запускаться внутри сеанса. Итак, в данный момент недостаток запуска xorg в качестве пользовательской службы заключается в том, что он должен запускаться с привилегиями суперпользователя (как до 1.16) и не может использовать преимущества непривилегированного режима, представленного в 1.16.

Вот как запустить xorg из пользовательского сервиса:

1. Заставить xorg работать с правами суперпользователя и для любого пользователя путем редактирования /etc/X11/Xwrapper.config

2. Добавить следующие юниты в

где $ — виртуальный терминал, на котором будет запущен xorg, либо прописанный в сервисном модуле, либо установленный в среде systemd с помощью

3. Обязательно настройте переменную среды DISPLAY , как описано выше.

4. Затем, чтобы активировать сокет для xorg на дисплее 0 и tty 2, следует выполнить:

Теперь запуск любого X приложения автоматически запустит xorg на виртуальном терминале 2.

Переменная среды XDG_VTNR может быть установлена в среде systemd из .bash_profile , а затем можно запустить любое приложение X, включая диспетчер окон, как системный модуль, зависящий от xorg@0.socket .

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

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

This article or section is out of date.

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

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

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

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

Как только это будет сделано, systemctl —user enable tmux.service , multiplexer.target и любые сервисы, которые вы создали для запуска cruft.target , и вы должны быть готовы к работе! Активирован user-session@.service , как описано выше, но обязательно удалите Conflicts=getty@tty1.service из <>, поскольку ваш пользовательский сеанс не будет принимать TTY. Поздравляем! У вас есть работающий терминальный мультиплексор и некоторые другие полезные программы, готовые к запуску при загрузке!

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

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

/.config/systemd/user/wm.target.wants /window_manager.service , позволяя ему стартовать при входе в систему. Рекомендуется включить этот сервис, а не связывать его вручную.

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

Arch Linux создает пакет systemd с помощью —without-kill-user-process , устанавливая KillUserProcesses равным no по умолчанию. Этот параметр предотвращает уничтожение пользовательских процессов, когда пользователь полностью выходит из системы. Чтобы изменить это поведение и убить все пользовательские процессы при выходе из системы, установите KillUserProcesses=yes в /etc/systemd/logind.conf .

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

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

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

После завершения всех активных сеансов user@.service прекращает работу, если для этого пользователя не был включён lingering [7]. Поэтому для запуска и работы долгосрочных процессов после полного выхода пользователя из системы необходимо включить lingering. Подробнее см. #Автоматический запуск systemd от имени пользователя и loginctl(1) .

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

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

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

Источник