Как разрешить systemd (code = exited, status = 227 / NO_NEW_PRIVILEGES)?
env присутствует в /usr/bin практически на всех Unix-подобных системах, которые все еще существуют в 21 веке. Два исключения, о которых я знаю, это SCO OpenServer (который все еще работает на нескольких очень старых серверах) и NextSTEP (не может быть много поддерживаемого оборудования, которое не умерло). Для переносимости используйте #!/usr/bin/env. Все остальное менее переносимо (за исключением #!/bin/sh, который несет свои собственные проблемы и полезен только в том случае, если вы планируете запускать свой сценарий на SCO).
POSIX и Single Unix не определяют /usr/bin/env, или /bin/sh, или любой абсолютный путь, кроме /, /tmp, и нескольких записей в /dev. /usr/bin/env не является формальным стандартом Unix, но это очень важный стандарт де-факто.
#!env совершенно бесполезен. Поиск в Shebang не использует переменную PATH, это делает ядро. (И если бы оно делало поиск PATH, то вы могли бы с тем же успехом написать #!bash напрямую)
#!/usr/bin/env bash совершенно нормально подходит для сценария bash, и я сомневаюсь в мудрости сопровождающего, который отклонил изменение от #!/bin/bash. Похоже, что сопровождающий был взволнован запросом и затем не воспринял его всерьёз. Изменение на использование стандартного sh вместо bash ещё лучше для переносимости, но видимо, это не сработало (вероятно, в скрипте осталась нестандартная конструкция). Если преобразование скрипта для работы в других оболочках было невозможно, то скрипт всё же следовало изменить, чтобы использовать #!/usr/bin/env bash вместо #!/bin/bash.
Я бы предположил, что вы столкнулись с этим в результате директивы systemd NoNewPrivileges=. Предполагая, что пакет redis-server обычно работает на системах Ubuntu 16.04, это наводит на мысль, что в вашей системе могут быть собственные глобальные настройки для NoNewPrivileges= или связанная с ней директива, из-за которой Redis не запускается.
Прочитайте документацию по ссылке о NoNewPrivileges= и связанных с ней директивах, затем найдите в каталоге /etc/systemd/, чтобы проверить, не были ли какие-либо из этих значений настроены в вашей системе. Если нет, убедитесь, что устанавливаемый вами пакет redis действительно поддерживается версией операционной системы, на которую вы его устанавливаете.
Вы можете установить PrivateDevices=false в сервисном файле systemd, чтобы он заработал.
Делаю резюме:
Вам необходимо добавить в файл /etc/systemd/system/redis.serviceследующие строки:
NoNewPrivileges=no
PrivateDevices=no
После бессчетного количества раз я обнаружил, что исправления работают.
В декабре 2017 года эта ошибка была обнаружена как ошибка Debian, но ошибка была устранена без исправления службы. Если у вас есть данные, которые запросил Крис Лэмб, предоставьте их.
Об аналогичной проблеме сообщалось для пакета Debian MariaDB 10.1 еще в июле 2017 г., который был закрыт без исправления, когда пакет был удален из Debian.
Локальное исправление заключается в изменении настроек службы на
NoNewPrivileges=no PrivateDevices=no
Не редактируйте /etc/systemd/system/redis.serviceили /usr/lib/systemd/system/redis-server.serviceнапрямую. Последний вообще не должен -редактироваться вручную локальными администраторами, а первый не является фактическим файлом модуля обслуживания, поставляемым с пакетом Debian.
Вместо этого используйте systemctl edit redis.serviceдля создания перетаскивания юнитов -в файле и поместите туда настройки. Это также неявно выполняет daemon-reload, что пришлось бы делать вручную, если бы вручную модифицировались юнит-файлы.
Для тех, кто пытается найти это в пакете с исходным кодом :Упакованные файлы redis.serviceи redis@.serviceгенерируются программой Debian под названиемgenerate-systemd-service-files.
Это одна из нескольких проблем, с которыми люди столкнулись при использовании механизмов ограничения systemd в служебных модулях, которые создаются и упаковываются людьми Debian. Другие заключаются в том, что его настройка ProtectHome=yesостанавливает работу символически связанного /homeиз-за ошибки панели запуска, а его настройка ReadOnlyDirectories=/приводит к коду ошибки 226/NAMESPACE в вопросах и ответах StackOverflow. Локальное исправление имеет одинаковую форму для всех, вставка -в юнит-файл с переопределением настроек.
Дополнительная литература
- Мауро Зилиани (2017 -12 -19 ).redis -выход с сервера с кодом 227/NO _NEW _PRIVILEGES. Ошибка Debian #884764.
- Эндрю Франс (2016 -11 -01 ).сервер redis -не запускается после обновления с 16.04 до 16.10. Ошибка панели запуска #1638410.
- https://stackoverflow.com/a/48496530/340790
- оззлой палиндромморднилап (2017 -07 -03 ).Установка mariadb завершается с ошибкой НЕТ _НОВЫЕ _ПРИВИЛЕГИИ (systemd). Ошибка Debian #867137.
- systemctl -коды выхода службы и объяснение информации о состоянии
В моем случае я использовал старое ядро Linux из предыдущей версии Debian, и несколько служб не запускались с ошибкой «(code=exited, status=227/NO _NEW _PRIVILEGES )».. Например:
ExecStart=/lib/systemd/systemd-logind (code=exited, status=227/NO_NEW_PRIVILEGES)
Установка ядра текущего дистрибутива с sudo apt-get install linux-image-amd64 && rebootустранила мою проблему.