Weiterführende Literatur

Weiterführende Literatur

Ich versuche, das GitLab-Community-Paket auf einem Debian-Stretch-System zu installieren, aber die Installation einer seiner Abhängigkeiten redis-serverschlä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 NoNewPrivilegesneu 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:yesnoredis.servicejournalctl -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-serverPaket 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 redisvon 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.serviceoder nicht /usr/lib/systemd/system/redis-server.servicedirekt. 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.servicezum Erstellen einesUnit-Drop-In-Dateiund legen Sie die Einstellungen dort fest. Dies führt auch daemon-reloadimplizit 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.serviceDateien [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=yesEinstellung 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

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 && rebootmein Problem behoben.

verwandte Informationen