Как запустить Linux как службу
Обновлено: 30.06.2024
Следуя приведенному выше руководству по установке, независимо от того, решите ли вы загружать двоичные файлы или собирать из исходного кода, OrientDB не устанавливается на системном уровне. Есть несколько дополнительных шагов, которые необходимо предпринять, чтобы управлять системой баз данных как службой.
OrientDB поставляется со сценарием, позволяющим управлять сервером базы данных как демоном системного уровня. Вы можете найти его в пути bin/ вашего установочного каталога (то есть в $ORIENTDB_HOME/bin/orientdb.sh .
Сценарий поддерживает три параметра:
Настройка скрипта
Чтобы использовать сценарий в вашей системе, вам необходимо отредактировать файл, чтобы определить две переменные: путь к каталогу установки и пользователя, для которого вы хотите запустить сервер базы данных.
Измените переменную ORIENTDB_DIR, указав каталог установки. Отредактируйте переменную ORIENTDB_USER, чтобы указать пользователя, для которого вы хотите запустить сервер базы данных (например, orientdb ).
Установка скрипта
Разные операционные системы и дистрибутивы Linux имеют разные процедуры управления системными демонами, а также процедуры их запуска и остановки во время загрузки и завершения работы. Ниже приведены общие руководства для unix-систем на основе init и systemd, а также для Mac OS X. Для получения дополнительной информации см. документацию для вашей конкретной системы.
Установка для инициализации
Многие Unix-подобные операционные системы, такие как FreeBSD, большинство старых дистрибутивов Linux, а также текущие выпуски Debian, Ubuntu и их производных, используют варианты инициализации в стиле SysV для этих процессов. Обычно это системы, которые управляют такими процессами с помощью сервисной команды.
Чтобы установить OrientDB в качестве службы в системе Unix или Linux на основе инициализации, скопируйте измененный файл orientdb.sh из $ORIENTDB_HOME/bin в /etc/init.d/:
После этого вы можете запускать и останавливать OrientDB с помощью служебной команды:
Установка для systemd
В большинстве новых выпусков Linux, особенно среди дистрибутивов на основе RPM, таких как Red Hat, Fedora и CentOS, а также в будущих выпусках Debian и Ubuntu для этих процессов используется systemd. Это системы, которые управляют такими процессами с помощью команды systemctl.
Пакет OrientDB содержит файл дескриптора службы для дистрибутивов на основе systemd. Служба orientdb.service размещается в каталоге bin. Чтобы установить OrientDB, скопируйте orientdb.service в каталог /etc/systemd/system (отметьте это, может зависеть от дистрибутива). Отредактируйте файл:
Установите правильного пользователя и группу. Вы можете использовать абсолютный путь вместо переменной окружения $ORIENTDB_HOME. После сохранения этого файла вы можете запускать и останавливать сервер OrientDB с помощью команды systemctl:
Кроме того, сохранив файл orientdb.service, вы можете настроить systemd на автоматический запуск сервера базы данных во время загрузки, введя команду enable:
Установка для Mac OS X
Ручная установка
- выполните действия, описанные выше в разделе «Настройка скрипта».
- создайте псевдоним для сценария системного демона OrientDB и консоли.
Теперь вы можете запустить сервер базы данных OrientDB с помощью следующей команды:
После запуска база данных становится доступной через сценарий консоли.
OrientDB доступен через brew.
Процесс установки дает результат, аналогичный следующему:
В процессе установки устанавливается пароль пользователя root по умолчанию для сервера, который необходимо изменить. Файл orientdb-server-config.xml устанавливается в /usr/local/Cellar/orientdb//libexec/config/. Откройте файл и удалите запись пользователя «root». Удалите тег true в конце файла. Запустите сервер в интерактивной консоли:
Сценарий запрашивает новый пароль для пользователя root базы данных.
Другие ресурсы
Чтобы узнать больше о том, как установить OrientDB в конкретной среде, следуйте приведенному ниже руководству:
Службы — это важные фоновые процессы, которые обычно запускаются при загрузке и завершают работу вместе с ОС.
Если вы системный администратор, вы будете регулярно иметь дело со службой.
Если вы обычный пользователь настольного компьютера, вам может потребоваться перезапустить службу, например настройку барьера для совместного использования мыши и клавиатуры между компьютерами. или когда вы используете ufw для настройки брандмауэра.
Сегодня я покажу вам два разных способа управления службами. Вы научитесь запускать, останавливать и перезапускать службы в Ubuntu или любом другом дистрибутиве Linux.
системд против инициализации
Ubuntu и многие другие современные дистрибутивы используют systemd вместо старого доброго init.
В systemd вы управляете службами с помощью команды systemctl.
В инициализации вы управляете сервисом с помощью сервисной команды.
Вы заметите, что даже несмотря на то, что ваша система Linux использует systemd, она по-прежнему может использовать сервисную команду (предназначенную для использования с системой инициализации).Это связано с тем, что служебная команда фактически перенаправляется на systemctl. Это своего рода обратная совместимость, введенная systemd, потому что системные администраторы привыкли использовать сервисную команду.
В этом руководстве я покажу как команду systemctl, так и сервисную.
Здесь я использую Ubuntu 18.04, но процесс (без каламбура) одинаков для других версий.
Способ 1. Управление службами в Linux с помощью systemd
Я начинаю с systemd по очевидной причине его широкого распространения.
1. Список всех услуг
Чтобы управлять службами, сначала необходимо узнать, какие службы доступны в вашей системе.
Вы можете использовать команду systemd, чтобы вывести список всех служб в вашей системе Linux:
Эта команда выводит состояние всех служб. Значение состояния службы может быть включено, отключено, замаскировано (неактивно, пока маска не будет снята), статично и сгенерировано.
Объедините это с командой grep, и вы сможете отобразить только запущенные службы:
Теперь, когда вы знаете, как ссылаться на различные сервисы, вы можете приступить к их активному управлению.
Примечание: в командах следует заменить имя службы, которой вы хотите управлять (например, network-manager, ufw и т. д.).
2. Запустить службу
Чтобы запустить службу в Linux, вам просто нужно использовать ее имя следующим образом:
3. Остановить службу
Чтобы остановить службу systemd, вы можете использовать опцию остановки команды systemctl:
4. Перезапустить службу
Чтобы перезапустить службу в Linux с помощью systemd, вы можете использовать:
5. Проверить статус службы
Вы можете подтвердить, что вы успешно выполнили определенное действие, распечатав статус службы:
Это выведет информацию следующим образом:
Это был systemd. Давайте переключимся на инициализацию.
Способ 2. Управление службами в Linux с помощью init
Команды в init такие же простые, как и системные.
1. Список всех услуг
Чтобы получить список всех служб Linux, используйте
Службы, которым предшествует [ – ], отключены, а службы с [ + ] включены.
2. Запустить службу
Чтобы запустить службу в Ubuntu и других дистрибутивах, используйте эту команду:
3. Остановить службу
Остановить службу также просто.
4. Перезапустить службу
Если вы хотите перезапустить службу, введите следующую команду:
5. Проверить статус службы
Кроме того, чтобы проверить, достигнут ли желаемый результат, вы можете вывести статус услуги:
Это выведет информацию следующим образом:
Самое главное, это покажет вам, активна ли определенная служба (работает) или нет.
Подведение итогов
Сегодня я подробно описал два очень простых метода управления службами в Ubuntu или любой другой системе Linux. Надеюсь, эта статья была вам полезна.
По умолчанию большинство служб systemd настроены на запуск пользователем root, но есть также возможность создать собственный файл службы systemd и запускать его от имени определенного пользователя или группы, или и того, и другого. Поэтому в этой статье мы проверим и проверим шаги по запуску службы systemd от имени конкретного пользователя и группы с использованием среды Linux CentOS/RHEL 7/8.
Я установил Oracle VirtualBox на сервер Linux, где я буду использовать виртуальную машину с RHEL/CentOS 7/8, чтобы проверить действия, описанные в этой статье.
Еще несколько статей на похожую тему:
- Как выполнить команду или скрипт с помощью systemd только при завершении работы, а не при перезагрузке в Linux
- Как выполнить команду или скрипт с помощью systemd прямо перед тем, как на терминале появится запрос на вход в систему в Linux
- Как выполнить команду или сценарий при запуске системы с помощью systemd без использования cronjob в Linux
- Как выполнить команду или сценарий после N минут загрузки (запуска системы) с помощью systemd в Linux
- Как остановить перезагрузку или завершение работы системы и прочитать ввод пользователя на этапе загрузки в Linux
- Как выполнить команду или сценарий с помощью systemd непосредственно перед завершением работы в Linux
- Как запустить службу от имени конкретного пользователя или группы с помощью systemd в Linux
Шаг 1. Обзор systemd
Надеюсь, вы уже знакомы с приведенными ниже темами
Шаг 2. Создайте пользователя и группу
Теперь это необязательные шаги, если у вас уже есть пользователь и группа, готовые к следующим шагам. Но если вы этого не сделаете, вы можете следовать этой статье, чтобы создать нового пользователя и назначить пользовательскую группу (основную или дополнительную) соответствующему пользователю.
Здесь я уже создал пользователя deepak, который является частью группы deepak и admin
Чтобы проверить группы любого пользователя
Итак, мы хотим создать файл сервисного модуля systemd и запустить сервис systemd от имени конкретного пользователя и группы, которые для нас будут частью пользователя Deepak группы администраторов
Шаг 3. Создайте пример сценария
Мы будем использовать наш сценарий запуска из старых статей с некоторыми изменениями, чтобы проверить и запустить службу systemd от имени конкретного пользователя и группы в Linux
Поэтому в этом сценарии мы добавили явную проверку для пользователя, поэтому, если пользователь, выполняющий сценарий, не является " дипак ", сценарий не будет выполнен. В случае успеха скрипт продолжит запись в /opt/golinuxcloud/file в течение 3 минут с интервалом в 1 минуту. Это также поможет нам убедиться, что скрипт не завершится до завершения определенной задачи
Измените владельца файла скрипта на deepak
Предоставить скрипту разрешение на выполнение
Мы выполним скрипт вручную, чтобы убедиться, что он работает должным образом
Шаг 4. Создайте юнит-файл для запуска службы systemd от имени определенного пользователя и группы
Теперь, как указано в шаге 1, я уже написал другую статью с инструкциями по созданию нового файла модуля systemd. Здесь мы назовем наш файл модуля systemd как run-as-user.service в /etc/systemd/system. Ниже приведено содержимое run-as-user.service
Здесь мы определили User=deepak и Group=admin, чтобы убедиться, что скрипт будет выполняться только от имени пользователя deepak, входящего в группу администраторов.
Вы также можете использовать многие другие директивы, если это необходимо в вашей среде, такие как WorkingDirectory , EnvironmentFile и т. д. Для получения дополнительной информации см. справочную страницу systemd.exec
Вы также можете создать свою собственную справочную страницу со списком инструкций для сценария или пользовательского инструмента, который вы создали. В производственной среде реального времени всегда рекомендуется также создавать и выпускать справочную страницу для каждого сценария или инструмента, который мы разрабатываем.
Обновите файлы конфигурации systemd
Далее включите службу (если требуется) для автоматического запуска при загрузке
Шаг 5. Проверьте конфигурацию файла модуля systemd
Теперь, когда мы закончили настройку systemd. Давайте проверим нашу конфигурацию. Прежде чем начать, я очистил содержимое /opt/golinuxcloud/file, куда наш скрипт /opt/golinuxcloud/startup_script.sh будет помещать фиктивный контент каждые минуты в течение 3 минут.
Далее проверьте статус службы
Похоже, все было хорошо, так как мы смогли запустить службу systemd от имени определенного пользователя и группы, вы можете проверить статус ps, чтобы убедиться, что наш скрипт работает, используя следующую команду:
Теперь вы можете отслеживать содержимое /opt/golinuxcloud/file в течение нескольких минут, как настроено в скрипте
Наконец, я надеюсь, что шаги из статьи по запуску службы systemd от имени конкретного пользователя и группы в CentOS/RHEL 7/8 Linux были полезны. Итак, дайте мне знать ваши предложения и отзывы, используя раздел комментариев.
Похожие поисковые запросы: запустить службу от имени пользователя linux. systemd позволяет пользователю запускать службу. systemd запускает службу как пользователь при загрузке. Служба linux systemd запускается от имени пользователя root. Перезапуск службы systemd только от имени конкретного пользователя? Службы systemd терпят неудачу с User= в файле службы. Запустить процесс от имени конкретного пользователя. как полностью запустить службу пользователю без полномочий root?
Похожие сообщения
Не нашли то, что искали? Выполните быстрый поиск в GoLinuxCloud
Если мои статьи о GoLinuxCloud помогли вам, пожалуйста, купите мне кофе в знак признательности.
Для любых других отзывов или вопросов вы можете использовать раздел комментариев или форму обратной связи.
Спасибо за поддержку!!
21 мысль на тему “Как запустить службу systemd от имени конкретного пользователя и группы в Linux”
Что такое группа «admin»? У меня есть «корневая» группа, но нет группы администраторов.
используемая здесь группа администраторов является примером
Разве не следует использовать функцию systemd «-user», чтобы разрешить учетным записям без полномочий root запускать свои собственные службы, не беспокоя при этом администратора с полномочиями root каждый раз, когда он хочет что-то изменить?
Мне бы хотелось реальный пример этого…
Любой сервис уровня приложения выполняется обычным пользователем, например apache
Чувак, ты действительно мне помог, спасибо большое, чувак!
Любимый! Очень хорошо объяснил!
Это действительно полезно, спасибо. Это также довольно своевременно, поскольку я пытаюсь заставить службу работать с небольшими изменениями, и, возможно, у вас есть некоторое представление об этом.
Я использую VirtualBox с гостевой ОС Ubuntu 20.04 и хостом Windows 10. Виртуальная машина определяется с общей папкой на хосте.
Мне нужно запустить службу от имени моего пользователя, и она должна создать несколько файлов и каталогов в общей папке.
Происходят действительно странные вещи.
– Я не могу ничего записать в общую папку, когда запускаю скрипт как сервис. Я всегда получаю ошибки «Отказано в доступе».
Нет проблем, если я запускаю службу как «sudo service xxx start», только когда она запускается при инициализации системы. В частности, у меня есть
«After=.mount» в разделе «Инициализация».
– Если я запускаю с помощью «+» перед именем сценария в ExecStart, он запускается от имени пользователя root и создает файлы, но затем они просто исчезают. На самом деле
они появляются только в скрипте (например, если я ввожу команду «ls»), но к тому времени, когда я вхожу в систему, они исчезают.
В любом случае, я рву на себе те маленькие волосы, которые у меня есть, и ничего не могу сделать. Мы будем очень признательны за любую информацию.
Извините, я не знал, что нельзя использовать угловые скобки. Мое «After=.mount» должно было быть «After=shared-folder-dir.mount», скопировано из списка systemctl list-units.
Привет, Алан,
Если требуется определенная файловая система, вместо After= следует использовать RequiresMountsFor=/path/to/fs .
Несколько вопросов:
Если вы просто запускаете сценарий от имени пользователя, может ли сценарий выполнять операции записи в общую папку? – Я полагаю, да?
Потому что, если это работает, нет никаких причин, по которым он не будет работать как служба systemctl.
Или вы видите проблемы с записью на этапе перезагрузки?
Если у меня будет больше информации, я могу попытаться воспроизвести поведение в своей среде.
Я вижу много комментариев. Не могли бы вы объединить и отправить мне письмо
Спасибо за ответ и за то, что посмотрели это, чтобы ответить на ваши вопросы:
– Просто запускаю сервис после авторизации, все работает, могу писать в общую папку с сервисом.
– действительно странно то, что у меня есть операторы эха, показывающие, что когда я запускаю от имени пользователя root:
– я могу писать в общую папку
– скрипт видит файлы и каталоги через ls правильно после создания
– в какой-то момент они исчезают. эти файлы нигде не удаляются, но доступ к некоторым из них осуществляется
программой java, которую вызывает скрипт. некоторые нет. но все они исчезают к тому времени, когда я могу войти
и посмотреть.
Во-первых, большое спасибо за этот хороший урок. Это то, что я ищу.
Но я столкнулся с проблемой. На моей одной тестовой виртуальной машине она работает нормально, а затем я попытался выполнить ту же процедуру на другой машине (важная виртуальная машина), но служба не запустилась. Я попытался запустить приложение вручную, оно работает нормально (владелец statsup.sh не является пользователем root).
Затем я закомментировал пользователя и группу в файле модуля в systemd, и он снова работает. Итак, я предполагаю, что проблема связана с служебным файлом systemd. Пожалуйста, подскажите, что делать?
Спасибо за отзыв.
Будет ли работать, если вы попытаетесь запустить приложение с помощью службы systemd вручную?
Проверили ли вы журналы «journalctl -b» на наличие каких-либо подсказок?
Подсказка от Journalctl >> catalina.sh говорит, что в доступе отказано (поскольку мое приложение вызывает catalina.sh)
В моей виртуальной машине нет службы tomcat, а владельцем catalina.sh является root,
но в моей цели машина (где у меня проблема) есть служба tomcat, и она остановлена, а владельцем catalina.sh является tomcat
И что значит запустить приложение с помощью службы systemd вручную? (я новичок)
Подскажите, пожалуйста, что делать?
Я не уверен, что полностью понимаю сценарий. На вашей целевой виртуальной машине, если ваша служба должна быть запущена с правами root, вы можете удалить аргумент пользователя и группы в файле модуля systemd. Идея состоит в том, чтобы сначала понять требование, вы упомянули, что служба systemd не может запустить службу автоматически, поэтому означает ли это, что служба оказывается «мертвой» или служба вообще не запускается.
Может ли служба во время работы использовать пользователя домена вместо локального пользователя.
Например, у нас есть пользователь домена, который будет иметь доступ к базе данных MSSQL на каком-то сервере.
Наша клиентская машина — Redhat Linux, на которой tomcat работает как служба.
Наш клиентский компьютер уже добавлен в тот же домен, что и база данных MSSQL.
Сервлету в нашем коте требуется доступ к базе данных MSSQL.
Вместо проверки подлинности SQL мы хотим использовать для этого проверку подлинности Windows. цель
Теперь как мы можем запустить tomcat от имени того же пользователя домена, который имеет доступ к базе данных MSSQL?
Вы можете просто поместить имя пользователя в поле User=USERNAME без каких-либо сведений о домене. Например, если ваш пользователь mysqldb — dbadmin, просто поместите User=dbadmin, и все должно работать. Если у вас также нет локального имени пользователя dbadmin, в этом случае может возникнуть конфликт, поэтому вам придется удалить локального пользователя.
Как я могу проверить, есть ли у нас системные привилегии или нет?
По умолчанию пользователи без полномочий root не имеют права использовать systemd для перезапуска/запуска/остановки служб, но у них должно быть разрешение на проверку состояния. Вы можете попытаться перезапустить любую службу, такую как sshd, и если у вас нет прав, то это должно завершиться ошибкой
Это ужасное место для размещения примера сценария в /tmp
Во многих системах, таких как fedora, tmp является файловой системой tmpfs, и сценарий исчезнет при перезагрузке.
Даже на «нормальном» /tmp, а не на tmpfs, файлы, которые не изменятся в течение определенного времени, будут удалены из /tmp через systemd-tmpfiles-clean.service
Да, это имеет смысл. Я понял, что в более поздних выпусках RHEL, CentOS по умолчанию tmp будет либо tmpfs, либо служба tmpfiles-clean будет часто очищать /tmp. Я обновил путь.
Я слышал, что существует несколько способов управления службами: system V init, systemd, upstart, . Какой из них я использую? служба man показывает, что это система V init. Но я слышал, что Linux заменяет init на systemd. Должен ли я использовать systemd вместо init в Ubuntu?
Как сделать произвольный исполняемый файл (ELF или сценарий оболочки) сервисом?
Относится ли что-либо из сообщения ниже ко мне?
Ubuntu 18.04 использует systemd. Сценарии в /etc/init.d используются только в том случае, если для службы не существует файла модуля systemd. Предпочтительно, чтобы службы systemd не демонизировались.
Здесь у вас 2 вопроса, и ответ на один не обязательно определяет ответ на другой. ОС Linux может иметь несколько диспетчеров демонов.
2 ответа 2
В Ubuntu 18.04 файлы [. ]
Я слышал, что существует несколько способов управления службами: system V init, systemd, upstart, . Какой из них я использую?
Вы используете systemd, это инициализация, поставляемая в Ubuntu 18.04. (Также в Ubuntu 16.04, Fedora, openSUSE, Arch Linux, RHEL 7, CentOS 7, CoreOS, а также по умолчанию в Debian 9.)
Хороший способ убедиться, что вы используете systemd, — выполнить команду systemctl . Если он доступен и выдает вывод при запуске, значит, вы используете systemd.
В Ubuntu 18.04 я могу запускать или останавливать некоторые службы,
я могу перечислять некоторые службы,
Обратите внимание, что сервисная команда, поставляемая в некоторых дистрибутивах systemd, предназначена в основном для обратной совместимости. Вместо этого вам следует попробовать управлять службами с помощью systemctl.
И вы можете найти статус всех объектов с помощью простого
Вывод соответствует файлам в каталоге /etc/init.d/ .
Это не обязательно относится к systemctl , так как собственные модули systemd хранятся в /etc/systemd/system/ и /usr/lib/systemd/system/ .
systemd обеспечивает совместимость со старыми сценариями инициализации SysV (через systemd-sysv-generator, который создает собственный сервисный модуль systemd, вызывающий команды из сценария инициализации), поэтому, если у вас есть сценарии инициализации в /etc/init.d/ , скорее всего, они появятся и в systemd.
Должен ли я использовать systemd вместо init в Ubuntu?
Этот вопрос не ясен.
Термин init обычно относится к первому процессу, запущенному при загрузке системы, процессу, запущенному с PID 1. systemd работает с PID 1, поэтому по определению systemd является процессом инициализации (и поэтому перед ним, а также инициализация SysV.)
Если вы спрашиваете: «Должен ли я использовать systemd вместо SysV init?», тогда вы уже используете systemd вместо SysV init, так как вы используете Ubuntu 18.04. (И, как указывалось выше, большинство дистрибутивов, которые вы бы выбрали в наши дни, скорее всего, будут включать systemd в качестве инициализации.)
Теперь вы можете спросить: "Должен ли я использовать системные модули вместо скриптов инициализации?" и этот вопрос более актуален, поскольку, возможно, у вас есть выбор, когда оба варианта будут работать.
Моя рекомендация заключается в том, что вы должны управлять службами с помощью модулей systemd, что является родным режимом работы. Создание сценария инициализации просто добавляет уровень косвенности (поскольку генератор все равно создаст для вас модуль systemd). Кроме того, написание модулей systemd проще, чем написание сценариев инициализации, поскольку вам не нужно беспокоиться о правильной демонизации и очистке. среду перед выполнением, так как systemd сделает все это за вас.
Как сделать произвольный исполняемый файл (либо ELF, либо сценарий оболочки) сервисом?
См. примеры на справочной странице. Самый простой пример показывает, как легко можно создать единицу обслуживания:
Сохраните этот модуль в /etc/systemd/system/foo.service , затем перезагрузите systemd, чтобы прочитать этот файл модуля с помощью:
Запустите службу с помощью:
И включите его во время запуска с помощью:
Вы можете проверить статус службы с помощью:
Конечно, systemd может сделать гораздо больше для управления службами, поэтому типичный модуль systemd будет длиннее этого (хотя и не обязательно намного сложнее). Просмотрите модули, поставляемые с Ubuntu, в /usr/lib /systemd/system/*.service, чтобы получить лучшее представление о том, что типично и чего ожидать.
Нет!Не работайте в фоновом режиме, не беспокойтесь о группах процессов или сеансах и т. д. systemd позаботится обо всем этом за вас. Просто напишите свой код для запуска на переднем плане, а systemd позаботится обо всем остальном.
(Если у вас есть служба, которая работает в фоновом режиме, systemd может управлять ею с помощью Type=forking , но все гораздо проще, если вы просто работаете на переднем плане, поэтому просто сделайте это, если вы запуск новой службы.)
Это касается приложений, использующих платформу Java "Spring Boot". Если вы не пишете код Java и не используете эту структуру, это не имеет значения. Если вы пишете код Java, попробуйте вместо этого просто запустить службу на переднем плане.
Вопрос о выскочке, ответ о сценариях инициализации SysV. Хотя сценарии инициализации SysV будут работать с systemd, предпочтительнее, чтобы вы писали модули systemd напрямую, как упоминалось выше.
Поэтому нет, я бы сказал, что ни то, ни другое не имеет значения.
Вместо этого я бы порекомендовал узнать больше о сервисных единицах systemd.
Этот сайт также является отличным ресурсом для этого, так что не стесняйтесь публиковать больше вопросов о нем, когда вы изучаете возможность написания собственных модулей systemd для своих служб.
Читайте также: