Astra linux systemctl access denied

systemd — Failed to enable unit: Access denied

Пытаюсь написать системд юнит, который будет просто запускать баш-скрипт.

Но он не хочет запускаться

Уже все опции поотключал — не пойму. Что ему надо?

А зачем нужно указывать интерпретатор, если он и так прописывается в первой же строчке скрипта?

у меня когда-то не работало без этого

Может он банально прав на исполнение твоего скрипта не имеет?

я ему в ExecStart уже левый скрипт подсунул, пустой — все равно эта ошибка.

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

ну так для этого и стоит ExecStart=/bin/bash .

простой пользователь не может управлять системными юнитами

для юзера запускается свой процесс управления юзерскими службами systemd —user

скрипт надо включать через него

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

зы. но ты натолкнул меня на мысль. я скопировал файл юнита в /etc/systemd/system и все запустилось. видать, он, действительно, не дает запустить, если файл лежит где-то в хомяке. как победить? мне же в репу гитовую его хочется добавить и держать там

пардон пропустил # в команде.

ситемные файлики должный лежать в системном месте юникс-вей же 🙂

man systemd.unit и усё вариантов нет.

сделай хардлинк в хомяк плюс chmod 666 ??

нет же. у меня на серверах с убунтой 16.04 сами файлы-юниты лежат то в хомяке, то еще где, а линки на них — в /etc/systemd/system. и все работает.

мне удалось автоматически создать линк, но демон не запускается

конечно! каждый раз

Ни разу не «зощитнег» системды, но звучит логично.

ситемные файлики должный лежать в системном месте юникс-вей же 🙂
и усё вариантов нет.

читай ман внимательнее — варианты есть, и даже не один.

1) К этим путям можно добавлять свои собственные, выставляя переменную окружения $SYSTEMD_UNIT_PATH

2) Можно вызвать systemctl link /path/to/your_unit.service , и затем уже запускать этот юнит стандартным способом

тред не читай, поскорее отвечай

мне удалось автоматически создать линк, но демон не запускается

Ты бы хоть ман почитал прежде чем на системд жаловаться. «systemctl enablre» *не* запускает твой сервис.

что ты хотел этим сказать?

У системде свое особое отношение к симлинакам. TLDR их нельзя юзать

И это все на моей ВПСке с убунтой 16.04 на борту.

Ровно то, что сказал. «systemctl start» запускает сервис, а «systemctl enable» — *разрешает* запускать его автоматически. При «systemctl enable» в /etc/systemd/system/multi-user.target.wants/ создаётся ссылка на твой юнит. Systemctl, видимо, эту ссылку создать не может. Ищи почему: настоящий ли ты рут, не мешает ли тебе селинукс или что-то подобное и т. д.

Systemctl, видимо, эту ссылку создать не может.

ну так я с этого и начал тред

Ищи почему: настоящий ли ты рут,

не мешает ли тебе селинукс или что-то подобное и т. д.

хм. Я, конечно, проверю еще раз селинукс… а что еще может мешать? не нашел я доков по этому поводу.

Ты начал тред с того, что заявил: «Но он не хочет *запускаться*», потом добавил: «Уже все опции поотключал — не пойму. Что ему надо?» Что ты называешь «опциями»? Те закоменнтаренные строчки в твоём юните? Твоя жалоба и вот эта строчка

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

Сходи в /etc/systemd/system, проверь есть ли там каталог multi-user.target.wanted, какие на него права, попробуй ручками создать там файл, попробуй сделать systemctl enable для какого-нибудь другого сервиса (желательно, у которого WantedBy такой же, как у твоего), сделай restorecon -Fv *, наконец посмотри логи, особенно логи аудита… Проблема решается, скорее всего, тривиально.

Ещё я бы положил свой юнит в /etc/systemd/system с последующим chmod go-w && restorecon -Fv — не исключено, что твой юнит файл открыт на запись кому угодно, а системд это не нравится.

Источник

systemd service: permission denied

I have a new systemd service that fails to start with a «permission denied» error. I bought a Thinkpad L480. Unfortunately, there seems to be an issue with the kernel not detecting the touchpad. This is addressed here can be solved by

As I do not want to do this on every single startup, I made a systemd service, which does not work as expected.

My touchpad_enabler.service is

The script file is simply

But I also tried it with the sh -c version. I adjusted the permissions via

so both files are owned by root. I then enabled it via

When I manually start the service via systemctl start touchpad_enabler.service , it works totally fine and the touchpad works as it should. However, on startup , the service fails and is listet as ‘failed’ in systemctl list-units .

The output of journalctl -b -u touchpad_enabler.service is:

It looks like the problem is the permission to write to the file itself. But manually starting the service works fine and to my understanding systemd should execute the command as root anyway, right?

From reading man systemctl.service I got the idea to prepend ‘+’ to the filepath so that it read

I do not really understand where this protocol file comes from. It looks like it gets created by the kernel on startup? So I also experimented with the After= parameter, but systemd should start the services after the kernel is fully loaded, right? The file is also owned by root so I would not expect any problems there.

I hope someone can help me. Thanks in advance.

Источник

Операционные системы Astra Linux

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

Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

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

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

1. инструкций и методических указаний по настройке и особенностям эксплуатации ОС, содержащих сведения о компенсирующих мерах или ограничениях по примене- нию ОС при эксплуатации;
2. отдельных программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, инструкций по их установке и настройке, а также информации, содержащей сведения о контрольных суммах всех файлов оперативного обновления;
3. обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.

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

Источник

Failed to list units: Access denied #8326

Comments

paulmenzel commented Mar 1, 2018

Submission type

systemd version the issue has been seen with

Used distribution

In case of bug report: Expected behaviour you didn’t see

systemclt list-units lists the units.

In case of bug report: Unexpected behaviour you saw

The error message Failed to list units: Access denied .

In case of bug report: Steps to reproduce the problem

systemctl status example.service works though, so it’s very confusing. The output of strace is attached.

The text was updated successfully, but these errors were encountered:

poettering commented Mar 2, 2018

Please generate the strace output with -s1000 or so, so that the dbus datagram data isn’t truncated.

Do you use any kind of weird MAC? selinux, …? Are you sure your dbus policy is in order?

paulmenzel commented Mar 2, 2018

Please find the non-truncated output attached.

Do you use any kind of weird MAC? selinux, …? Are you sure your dbus policy is in order?

No SELinux is used. I am not user about the D-Bus policy.

poettering commented Mar 2, 2018

This suggests that there’s something wrong with your dbus policy. Maye you still have the old policy installed, not the one that current systemd drops in?

paulmenzel commented Mar 2, 2018

Is there a way to query D-Bus for more verbose information?

The following files with dbus in the path are installed.

But, let’s close this, and I’ll reinstall the system again, as it seems to work on other systems.

dtwilliamson commented Mar 6, 2018 •

I have two Ubuntu 16.04 VMs that I just created at the same time and in the same way. One exhibits the problem and the other doesn’t. They both have systemd 229. Neither has systemd-shim
sudo dpkg —purge systemd-shim
dpkg: warning: ignoring request to remove systemd-shim which isn’t installed

I diffed straces from the two systems and these lines from system one (the failing one) stand out (lots of other lines snipped):

In the first of these two lines, the difference is that nodev\tbinfmt_misc\n doesn’t appear on the succeeding system.

This is the connect:

And, for contrast, this is what system two says where system one says «REJECTED»:

Источник

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

Введение

В данной статье рассказано про необходимость выполнения перезагрузки системы после выполнения процедуры обновления (upgrade) пакета systemd. Нижеописанное также будет относиться и к любым другим системным пакетам, для которых установлены обновления.

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

Перезагружать или не перезагружать

Для получения достоверного ответа, стоит обратиться к документации. Общеизвестно, что после обновления ядра, ОС необходимо перезапустить. Но существует ещё ряд компонентов системы, при обновлении которых также требуется reboot. Таковыми являются:

Red Hat Enterprise Linux 7:

Red Hat Enterprise Linux 8:

Да, среди списка присутствует systemd и казалось бы, что ответ на вопрос в самом начале статьи очевиден, но не всё так просто. Red Hat рекомендует перезагрузить систему после установки обновленного пакета. Это гарантирует, что все процессы и службы, использующие данный пакет, будут работать максимально корректно с учетом новых обновлений. Но при этом нет обязательных требований выполнять перезагрузку.

Так, обновляя openssl, очевидно, что потребуется выполнить перезапуск ещё и связанных сервисов, и от этого никуда не денешься. Но в случае с systemd можно сделать исключение, чтобы не тушить продуктивный сервер, особенно при наличии SLA.

Диагностика

Всё вышеописанное было лишь теорией и рекомендациями. А что насчёт реальной проверки? Для наглядного примера, на одной из ОС под управлением Centos 7 был обновлен пакет systemd до версии 219-78. В дистрибутивах RH-based есть возможность выполнить команду, которая покажет список обновленных пакетов и укажет на необходимость перезагрузки системы:

Также можно посмотреть список сервисов, которые необходимо перезапустить:

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

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

• -n – запрещает преобразование адресов в доменные имена для сетевых файлов. Это позволяет работать lsof быстрее
• -P – запрещает преобразование номеров портов в имена портов для сетевых файлов, что также позволяет работать lsof быстрее.
• +L1 – указывает, что выборке подлежат только unlinked-файлы.

Для конкретного процесса, если известен PID, подойдет следующая команда:

Таким образом, lsof показывает, какие файлы и для каких сервисов были изменены, а дальше уже нужно принять решение о необходимости перезапуска того или иного сервиса (системы). В данном случае, при обновлении systemd команда lsof для p1 вернула пустой результат, что косвенно может говорить о том, что выполнять перезапуск systemd после upgrade не требуется.

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

Которая по всей видимости и решает вопрос “мягкого” перезапуска systemd после его обновления:

В случае возникновения ошибки вида “Failed to read server status: Access denied”, её можно исправить следующим образом. По сути daemon-reexec посылает TERM сигнал, т.е. можно выполнить:

Заключение

В статье был рассмотрен вопрос необходимости перезагрузки системы после обновления пакета systemd. Резюмируя, можно сказать, что такой необходимости нет. При возникновении ситуации, когда нужно обновить и не перезагружать сервер, есть инструменты вида daemon-reexec.

Но всё это применимо, как мне видится, на каких-то системах, где нет ничего критичного. Лучше всегда запланировать даунтайм и выполнить плановую перезагрузку (совместив, например, с какими-то другими работами). Ведь даже Red Hat не зря рекомендует выполнять перезагрузку. А на каких-то крупных хайлоад-проектах есть балансировщики и кластеры с нескольким количеством нод, которые в любом случае можно и нужно обслуживать, а значит выводить из работы с их последующим даунтаймом.

Источник