Astra linux нет systemctl

Сервисы

Вот 1-й вопрос: этот набор комплектовщики дистрибутива поставили по дефаулту как самый общий, на усреднённого пользователя.
Но что здесь не всегда обязательно, можно остановить/удалить?

P.S. На этот вопрос подтолкнула тема, например, Долгий запуск графических приложений — где рассматривается работа дистрибутива на оборудовании с ограниченными ресурсами (памятью) . здесь пассивно выполняющиеся сервисы могут а). поджирать бесцельно процессорное время + б). занимать память, а при её нехватке вызывать активный своп, что опять выражается (ещё раз) снижением производительности.

Olej

New member

По идее, тот же список, но уже выполняющихся сервисов (демонов) даст и команда service в «старом стиле» (sysV а не systend):

root@astra:~# service --status-all [ + ] acpid [ + ] acpi-support [ - ] aldd [ - ] alsa-utils [ - ] anacron [ + ] avahi-daemon [ - ] console-setup.sh [ + ] cron [ - ] cryptdisks [ - ] cryptdisks-early [ + ] cups [ + ] dbus [ + ] dnsmasq [ - ] exim4 [ - ] firewalld [ + ] fly-dm [ + ] gpm [ - ] hwclock.sh [ - ] keyboard-setup.sh [ + ] kmod [ + ] libvirtd [ + ] libvirt-guests [ + ] networking [ + ] network-manager [ - ] nfs-common [ - ] ntp [ - ] openvpn [ - ] plymouth [ - ] plymouth-log [ + ] procps [ + ] quota [ - ] quotarpc [ + ] rpcbind [ + ] rsyslog [ + ] ssh [ + ] sssd [ - ] sudo [ + ] udev [ + ] ufw [ - ] virtlogd [ + ] virtualbox [ - ] x11-common

Причём команда service даст (как пишут) сервисы, которые запущены через systemd, так и сервисы из /etc/init.d, запущенные в старом стиле инициализации.

Olej

New member

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

olej@astra:~$ systemd-analyze blame 15.986s vboxadd.service 5.608s apt-daily.service 4.792s sssd.service 4.218s keyboard-setup.service 3.828s libvirtd.service 2.853s dev-sda1.device 2.765s apt-daily-upgrade.service 2.192s NetworkManager-wait-online.service 1.982s networking.service 1.598s virtualbox.service 1.580s NetworkManager.service 1.572s upower.service 1.082s rpcbind.service 1.025s quota.service 995ms rsyslog.service 944ms avahi-daemon.service 868ms alsa-restore.service 780ms systemd-udevd.service 750ms systemd-udev-trigger.service 661ms dnsmasq.service 617ms gpm.service 607ms systemd-modules-load.service 563ms quotarpc.service 557ms acpi-support.service 426ms ssh.service 419ms udisks2.service 411ms systemd-journald.service 410ms polkit.service 353ms systemd-logind.service 334ms libvirt-guests.service 330ms systemd-journal-flush.service 286ms run-rpc_pipefs.mount 284ms systemd-tmpfiles-setup-dev.service 207ms systemd-sysctl.service 164ms systemd-tmpfiles-setup.service 155ms sys-fs-fuse-connections.mount 147ms kmod-static-nodes.service 144ms dev-hugepages.mount 141ms user@999.service 139ms vboxadd-service.service 138ms systemd-remount-fs.service 135ms ufw.service 127ms plymouth-start.service 95ms user@1000.service 90ms plymouth-quit-wait.service 83ms console-setup.service 81ms fly-dm.service 76ms plymouth-read-write.service 73ms nfs-config.service 68ms dev-disk-by\x2duuid-7678ec6a\x2dd050\x2d4ed6\x2d96d0\x2dd9c89130c58f.swap 66ms sys-kernel-config.mount 66ms systemd-user-sessions.service 64ms dev-mqueue.mount 43ms sys-kernel-debug.mount 42ms plymouth-quit.service 30ms systemd-random-seed.service 28ms systemd-update-utmp.service 15ms systemd-update-utmp-runlevel.service 8ms systemd-tmpfiles-clean.service

olej@astra:~$ systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @22.432s └─multi-user.target @22.432s └─vboxadd-service.service @22.292s +139ms └─vboxadd.service @6.304s +15.986s └─basic.target @5.308s └─paths.target @5.306s └─acpid.path @5.306s └─sysinit.target @5.266s └─systemd-update-utmp.service @5.237s +28ms └─systemd-tmpfiles-setup.service @5.057s +164ms └─local-fs.target @5.042s └─local-fs-pre.target @5.042s └─keyboard-setup.service @823ms +4.218s └─system.slice @752ms └─-.slice @647ms

Во-первых, таким образом можно отследить «виновника» в тех случаях, когда загрузка системы становится до неприличного длительной (при разных внесенных изменениях).
Но, самое интересное, из этой длинной цепочки путём конфигурации systemd можно повыбрасывать (запретить) те сервисы-юниты, которые не нужны мне в конкретных условиях. Утверждается, что в некоторых случаях такой оптимизацией под свои нужды время перезагрузки системы можно уменьшить в разы.

Источник

Исправлено: команда Systemctl не найдена

Systemctl — это утилита Systemd для управления службами и процессами в дистрибутивах Linux. Используя команду systemctl, вы можете легко запускать и останавливать службы через Терминал. Однако несколько пользователей получают ошибку « systemctl: команда не найдена » при попытке запустить команду systemctl. Эта проблема чаще всего возникает в устаревших версиях операционных систем Linux, которые не поддерживают Systemd.

Команда Systemctl не найдена

Что является причиной ошибки ‘Systemctl command not found’?

Согласно нашим исследованиям, основной причиной проблемы является устаревшая операционная система. Некоторые устаревшие дистрибутивы Linux используют SysV init и Upstart вместо Systemd, из-за чего команды systemctl не будут работать в Terminal. Systemd был представлен в последних версиях операционных систем и недоступен для устаревших версий.

Теперь, когда вы знаете причину, по которой возникла проблема, мы перейдем к ее решению.

Сервисная команда для устаревших дистрибутивов Linux

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

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

Нажмите одновременно клавиши CTRL + ALT + T, чтобы открыть терминал, и введите следующую команду, чтобы запустить службу:

sudo serviceasticsearch start 

статус службы поиска 

Запуск услуги и проверка статуса
И некоторые сервисы, такие какasticsearch, имеют собственную команду для тестирования:

curl –X GET '// localhost: 9200' 

Тестирование службы эластичного поиска

Бонус: команда Systemctl для последних дистрибутивов Linux

Systemd заменил инициализацию SysV в качестве системы инициализации в большинстве дистрибутивов Linux. Команда Systemctl будет работать для последних дистрибутивов Linux без каких-либо ошибок, как показано ниже:

1. Нажмите клавиши CTRL + ALT + T вместе, чтобы открыть терминал
2. Введите команду systemctl, чтобы запустить службу:

sudo systemctl start эластичный поиск 

Запуск службы с помощью команды systemctl

Источник

Как в Linux пользоваться systemctl и systemd

Обновлено: 15.04.2022 Опубликовано: 06.09.2016

Вместе с подсистемой systemd появилась команда systemctl. Она позволяет управлять основными процессами Linux. Ниже представлена небольшая инструкция в виде шпаргалки наиболее используемых команд.

Общий синтаксис

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

Примерный вывод команды: 1) название юнита;
2) тип юнита (например, service: служба или демон, mount: точка монтирования, device: устройства);
3) состояние юнита (загружен или нет);
4) обобщенный статус юнита (active: выполняется, inactive: не был запущен, maintenance: требуется внимание администратора);
5) текущий статус (запущен или нет);
6) описание.

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

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

* перезагрузит локальный сервер. 9. Проверка работы сервиса. Выполняется с помощью опции is-active:

. приведет к выполнению команды docker run hello-world только в том случае, если сервис docker работает.

Автозапуск

Подсистему systemd также можно использовать для автозапуска сервисов или скриптов. Для этого в каталоге /usr/lib/systemd/system создаем юнит (файл) с расширением .service. Подробнее разберем на примере сервиса bind:

[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Wants=named-setup-rndc.service
Before=nss-lookup.target
After=network.target
After=named-setup-rndc.service

[Service]
Type=forking
Environment=NAMEDCONF=/etc/named.conf
EnvironmentFile=-/etc/sysconfig/named
Environment=KRB5_KTNAME=/etc/named.keytab
PIDFile=/run/named/named.pid
ExecStartPre=/bin/bash -c ‘if [ ! «$DISABLE_ZONE_CHECKING» == «yes» ]; then /usr/sbin/named-checkconf -z «$NAMEDCONF»; else echo «Checking of zone files is disabled»; fi’
ExecStart=/usr/sbin/named -u named -c $ $OPTIONS
ExecReload=/bin/sh -c ‘/usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID’
ExecStop=/bin/sh -c ‘/usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID’
PrivateTmp=true

• Unit — позволяет определить метаданные для юнита.
• Service — раздел для основной конфигурации юнита.
• Install — определение поведения для юнита при его включении или отключении.

Подробнее можно почитать о структуре и возможных опциях на странице https://linux-notes.org/pishem-systemd-unit-fajl/

После внесения изменений и сохранения файла, необходимо перечитать изменения командой:

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

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

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

И так, мы для примера взяли юнит для bind. Чтобы создать для него drop-in файл, вводим:

И вносим, например, такие изменения:

* будет создан файл /etc/systemd/system/named.service.d/override.conf, который будет переопределять настройки основного юнит-файла. В данном примере, мы указываем на необходимость перезапуска сервиса при сбое.

Чтобы убедиться в использовании Drop-In файла смотрим статус сервиса:

Мы должны увидеть что-то на подобие:

Drop-In: /etc/systemd/system/named.service.d
— override.conf

Таймеры

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

Предположим, мы хотим создать запуск по таймеру named, для которого выше в примере создали юнит сервиса. Тогда создаем файл:

[Unit]
Description=Run named every 10 min

[Timer]
OnBootSec=5min
OnUnitActiveSec=10min

* в данном примере наш таймер будет создан для юнита named; он запустится через 5 минут после старта службы и будет запускать ее каждые 10 минут.

Перечитаем изменения в systemd:

systemctl enable named.timer

systemctl start named.timer

Вывести список таймеров можно командой:

Источник