LINUX.ORG.RU
решено ФорумAdmin

Не стартует сервис systemctl

 , ,


0

2

Здравствуйте, форумчане. Нужна очень Ваша помощь.

Ситуация такая: есть клиентский компьютер на базе ОС Astra Linux (debian). Настроено всё под работу многопотока «гостей». Мол: «Пришёл клиент 1, поработал с браузером, офисом, закончил работу ушёл; если следующий клиент не пришёл через 3 минуты (подсчёт времени бездействия) - выход из сеанса и автовход с удалением всех файлов предыдущего клиента, в том числе и очищение корзины». Помимо это также прописаны по средству systemd несколько юнитов, которые отрабатывают одну команду (каждый) при инициализации и отключении флешки из системы (рутокен и запись сертификата в личное хранилище. Это нужно для того, чтобы у пользователя был вход на необходимые ресурсы через ЭЦП). 2 дня назад обкатывал систему и всё работало «как часы». Уже готов был ввести на тестовую эксплуатацию для тестирования, но вот решил сегодня ещё раз проверить систему и столкнулся с тем, что юниты имеют статус «inactive», хотя до этого были в автозагрузке. Решаю запустить через «start» и происходит непонятное ожидание системы, то есть переход на следующую строку. Ждал минуту, две, пять, всё тщетно, ощущение, словно что-то ему нужно. Но я не понимаю что. По какой-то причине все прописанные мною systemd юниты ушли в инактив. Проверяю через journalctl --pager-end, но не вижу ошибок никаких (может неправильно интерпретирую вывод логов, скину ниже под хайд). Скажу сразу - знания линукса у меня дай бог на уровне новичка, что-то знаю, примерно понимаю, но пока что очень зелёный. Подскажите, пожалуйста, в чём может быть вообще проблема? Куда копать? Какую информацию изучить? Почему всё работало, а через 2 дня всё ушло в инактив? Всё необходимое скину, пока оставлю вывод journalctl --pager-end:

фев 01 13:0фев 01 13:06:47 WS2208-B18 sudo[9805]:    guest : TTY=pts/1 ; PWD=/usr/lib/systemd/system ; USER=root ; COMMAND=/usr/bin/systemctl start idle.service
фев 01 13:06:47 WS2208-B18 sudo[9805]: pam_kiosk2(sudo:session): need_continue: UID 0 detected, skipping. User: root
фев 01 13:06:47 WS2208-B18 sudo[9805]: pam_unix(sudo:session): session opened for user root by guest(uid=0)
фев 01 13:06:47 WS2208-B18 audit[9805]: USER_CMD pid=9805 uid=1001 auid=1001 ses=24 subj=0:0:0:0 msg='cwd="/usr/lib/systemd/system" cmd=73797374656D63746C20
фев 01 13:06:47 WS2208-B18 audit[9805]: SYSCALL arch=c000003e syscall=95 success=yes exit=18 a0=3f a1=61ace1741028 a2=ff a3=7f2f120f0540 items=0 ppid=9780 p
фев 01 13:06:47 WS2208-B18 audit: PROCTITLE proctitle=7375646F0073797374656D63746C0073746172740069646C652E73657276696365
фев 01 13:06:47 WS2208-B18 audit[9805]: SYSCALL arch=c000003e syscall=95 success=yes exit=63 a0=12 a1=0 a2=ffffffff a3=61ace1739010 items=0 ppid=9780 pid=98
фев 01 13:06:47 WS2208-B18 audit: PROCTITLE proctitle=7375646F0073797374656D63746C0073746172740069646C652E73657276696365
фев 01 13:06:47 WS2208-B18 audit[9805]: CRED_REFR pid=9805 uid=0 auid=1001 ses=24 subj=0:0:0:0 msg='op=PAM:setcred grantors=pam_permit acct="root" exe="/usr
фев 01 13:06:47 WS2208-B18 audit[9805]: USER_START pid=9805 uid=0 auid=1001 ses=24 subj=0:0:0:0 msg='op=PAM:session_open grantors=pam_permit,pam_unix,pam_li
фев 01 13:06:47 WS2208-B18 audit[9806]: SYSCALL arch=c000003e syscall=95 success=yes exit=18 a0=12 a1=0 a2=ffffffff a3=0 items=0 ppid=9805 pid=9806 auid=100
фев 01 13:06:47 WS2208-B18 audit: PROCTITLE proctitle=7375646F0073797374656D63746C0073746172740069646C652E73657276696365
фев 01 13:06:47 WS2208-B18 audit[9807]: SYSCALL arch=c000003e syscall=95 success=yes exit=18 a0=12 a1=0 a2=0 a3=0 items=0 ppid=9806 pid=9807 auid=1001 uid=0
фев 01 13:06:47 WS2208-B18 audit: PROCTITLE proctitle=2F62696E2F73797374656D642D7474792D61736B2D70617373776F72642D6167656E74002D2D7761746368
фев 01 13:06:48 WS2208-B18 audit[9808]: SYSCALL arch=c000003e syscall=95 success=yes exit=18 a0=0 a1=0 a2=ffffffff a3=5f0f1bf0a42a items=0 ppid=9780 pid=980
фев 01 13:06:48 WS2208-B18 audit: PROCTITLE proctitle=7375646F006A6F75726E616C63746C002D2D70616765722D656E64
фев 01 13:06:48 WS2208-B18 audit[9808]: SYSCALL arch=c000003e syscall=95 success=yes exit=0 a0=12 a1=0 a2=ffffffff a3=5f0f1bf0a42a items=0 ppid=9780 pid=980
фев 01 13:06:48 WS2208-B18 audit: PROCTITLE proctitle=7375646F006A6F75726E616C63746C002D2D70616765722D656E64
фев 01 13:06:48 WS2208-B18 audit[9808]: USER_ACCT pid=9808 uid=1001 auid=1001 ses=24 subj=0:0:0:0 msg='op=PAM:accounting grantors=pam_tally,pam_permit acct=
фев 01 13:06:48 WS2208-B18 sudo[9808]:    guest : TTY=pts/1 ; PWD=/usr/lib/systemd/system ; USER=root ; COMMAND=/usr/bin/journalctl --pager-end

и скрипт idle.service, на примере которого были сделаны записи в журнал:

[Unit]
Description=idle
After=multi-user.target

[Service]
Type=simple
User=guest
Group=guest
ExecStart=/usr/local/bin/idle.sh

[Install]
WantedBy=multi-user.target

Сам скрипт idle.sh работает, вручную запускаю, всё нормально. И до инактива всё работало. В общем, вот такая ерунда :(



Последнее исправление: dmitriyqwe (всего исправлений: 1)

Ответ на: комментарий от dmitriyqwe

Зачем используешь самописные решения, когда есть готовые?:

https://wiki.astralinux.ru/pages/viewpage.action?pageId=1998856

https://wiki.astralinux.ru/pages/viewpage.action?pageId=67108883

И в Astra есть мандатная система — это фирменная особенность, в других Linux такого нет и не будет.

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Киоск пробовался. Полгода назад была попытка, но неудачная. Мутно помню в чём там именно было дело, но было принято решение не использовать киоск, а «костыльно» изобрести велосипед.

dmitriyqwe
() автор топика
Ответ на: комментарий от user13

Это система прав доступа, что работает поверх обычных прав Unix, и дополнительно ограничивает действия пользователей ради большей безопасности.

Например, может запретить root читать какой-то файл, когда обычные права Unix на это не способны.

Но из-за их сложности и неочевидности с ними бывают проблемы — можешь почитать про отладку SELinux, например. В Astra не он, но представление о характере проблем дает.

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Благодарю за доп информацию. Ознакомлюсь, а то у меня все права доступа настроены через setfacl. Думаю использовать уже готовое решение от астры выглядит куда разумнее

dmitriyqwe
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

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

Это не пересекается. ACL нужен тогда, когда недостаточно простых прав, то есть для большей гибкости. MAC используется на файлах, чтобы обычные права (UNIX/ACL) не имели значения. Посмотри метки SELinux на .ssh или .gnupg.

А вот ПО в песочнице — через SELinux и подобным.

Спорное утверждение. Если брать Android, то наверное, но я никогда не вникал, как оно там настроено. Если не Android, то SELinux, можно сказать, почти нигде и не используется всерьёз. Но сэндбоксинг от этого никуда не девается, MAC здесь вовсе не основная техника, а скорее дополнительная. Например, libvirt и LXC могут использовать SELinux и AppArmor, если они доступны, но без этих систем изоляция никуда не денется, просто они дают дополнительные гарантии.

anonymous
()