
Ich versuche, das GitLab-Community-Paket auf einem Debian-Stretch-System zu installieren, aber die Installation einer seiner Abhängigkeiten redis-server
schlägt fehl, wenn der Dienst mit systemd gestartet wird.
Vollständiges Protokoll:
$ sudo dpkg --configure redis-server
Setting up redis-server (3:3.2.5-4) ...
Job for redis-server.service failed because the control process exited with error code.
See "systemctl status redis-server.service" and "journalctl -xe" for details.
invoke-rc.d: initscript redis-server, action "start" failed.
● redis-server.service - Advanced key-value store
Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2016-12-15 15:00:17 UTC; 31ms ago
Docs: http://redis.io/documentation,
man:redis-server(1)
Process: 8764 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=227/NO_NEW_PRIVILEGES)
Process: 8761 ExecStartPre=/bin/run-parts --verbose /etc/redis/redis-server.pre-up.d (code=exited, status=227/NO_NEW_PRIVILEGES)
Main PID: 24283 (code=exited, status=227/NO_NEW_PRIVILEGES)
Dec 15 15:00:17 Serverdatorn-Debian systemd[1]: redis-server.service: Unit entered failed state.
Dec 15 15:00:17 Serverdatorn-Debian systemd[1]: redis-server.service: Failed with result 'exit-code'.
dpkg: error processing package redis-server (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
redis-server
Das Starten des Redis-Servers durch manuelles Ausführen der ausführbaren Datei funktioniert einwandfrei:
$ sudo /usr/bin/redis-server /etc/redis/redis.conf
$ sudo tail /var/log/redis/redis-server.log
...
* The server is now ready to accept connections on port 6379
Wenn Sie weitere Informationen von mir wünschen, teilen Sie mir diese bitte mit.
BEARBEITEN:
Ich habe versucht, in der Datei beides einzustellen , sie NoNewPrivileges
neu zu laden und erneut zu starten, aber ohne Erfolg, derselbe Fehler. Ich habe festgestellt, dass beim Ausführen eine andere Meldung angezeigt wird, die hilfreich sein könnte:yes
no
redis.service
journalctl -xe
redis-server.service: Failed at step NO_NEW_PRIVILEGES spawning /usr/bin/redis-server: Invalid argument
Antwort1
Ich vermute, Sie stoßen auf das Ergebnis dersystemd
NoNewPrivileges=Direktive. Unter der Annahme, dass das redis-server
Paket im Allgemeinen auf Ubuntu 16.04-Systemen funktioniert, deutet dies darauf hin, dass Ihr System möglicherweise benutzerdefinierte globale Einstellungen NoNewPrivileges=
oder eine verwandte Direktive hat, die dazu führt, dass Redis nicht gestartet werden kann.
Lesen Sie die verlinkten Dokumente zu about NoNewPrivileges=
und den zugehörigen Anweisungen und suchen Sie dann in Ihrem /etc/systemd/
Verzeichnis, um zu sehen, ob einer dieser Werte auf Ihrem System angepasst wurde. Wenn nicht, bestätigen Sie, dass das redis
von Ihnen installierte Paket tatsächlich von der Betriebssystemversion unterstützt wird, auf der Sie es installieren.
Antwort2
Dies wurde bereits im Dezember 2017 als Debian-Fehler gemeldet, aber der Fehler wurde ohne Service-Fix geschlossen. Wenn Sie die von Chris Lamb angeforderten Details haben, geben Sie sie bitte an.
Ein ähnliches Problem wurde bereits im Juli 2017 für Debians MariaDB 10.1-Paket gemeldet und ohne Korrektur geschlossen, als das Paket aus Debian entfernt wurde.
Alokale Lösungbesteht darin, die Einstellungen des Dienstes so zu ändern,
NoNewPrivileges=nein PrivateDevices=nein
Bearbeiten Sie /etc/systemd/system/redis.service
oder nicht /usr/lib/systemd/system/redis-server.service
direkt. Letzteres sollte von lokalen Administratoren überhaupt nicht manuell bearbeitet werden, und Ersteres ist nicht die eigentliche Service-Unit-Datei, die mit dem Debian-Paket geliefert wird.
Verwenden Sie stattdessen systemctl edit redis.service
zum Erstellen einesUnit-Drop-In-Dateiund legen Sie die Einstellungen dort fest. Dies führt auch daemon-reload
implizit eine Aktion aus, die man manuell durchführen müsste, wenn man Unit-Dateien manuell ändern würde.
Für diejenigen, die versuchen, dies im Quellpaket zu finden: Die gepackten redis.service
Dateien [email protected]
werden von einem Debian-Programm namensgenerate-systemd-service-files
.
Dies ist eines von mehreren Problemen, die Leute mit der Verwendung der Einschränkungsmechanismen von systemd in den Service-Units hatten, die von den Debian-Leuten generiert und verpackt werden. Andere sind, dass seine ProtectHome=yes
Einstellung einen symbolisch verknüpften Dienst in einem Launchpad-Bug daran hindert /home
, zu funktionieren, und dass seine ReadOnlyDirectories=/
Einstellung einen Fehlercode 226/NAMESPACE in einem StackOverflow Q&A erzeugt. DaslokalDer Fix hat für alle die gleiche Form, eine Drop-In-Unit-Datei mit einer Einstellungsüberschreibung.
Weiterführende Literatur
- Mauro Ziliani (19.12.2017). Redis-Server wird mit dem Code 227/NO_NEW_PRIVILEGES beendet. Debian-Fehler Nr. 884764.
- Andrew Frankreich (01.11.2016). Redis-Server startet nach Upgrade von 16.04 auf 16.10 nicht. Launchpad-Fehler Nr. 1638410.
- https://stackoverflow.com/a/48496530/340790
- ozzloy Palindromordnilap (03.07.2017). MariaDB-Installation schlägt mit NO_NEW_PRIVILEGES fehl (systemd). Debian-Fehler Nr. 867137.
- systemctl - Erklärung der Service-Exitcodes und Statusinformationen
Antwort3
Sie können PrivateDevices=false in der systemd-Servicedatei festlegen, damit es funktioniert.
Antwort4
In meinem Fall habe ich einen alten Linux-Kernel einer früheren Debian-Version verwendet und einige Dienste konnten nicht mit dem Fehler „(code=exited, status=227/NO_NEW_PRIVILEGES)“ gestartet werden. Beispiel:
ExecStart=/lib/systemd/systemd-logind (code=exited, status=227/NO_NEW_PRIVILEGES)
Die Installation des aktuellen Distributionskernels hat sudo apt-get install linux-image-amd64 && reboot
mein Problem behoben.