Was verursacht "systemd: Fehler bei Schritt USER spawning / usr / sbin / opendkim: Kein solcher Prozess"

21

Wie kann ich folgenden Fehler entfernen:

systemd: Failed at step USER spawning /usr/sbin/opendkim: No such process

Es tritt auf, wenn ich versuche, den opendkim-Dienst auf Centos zu starten.

linux

— Syed
quelle

Ich habe diesen Fehler erhalten, weil ich den falschen Benutzer und die falsche Gruppe eingegeben habe. Auf Debian funktionierte es mit dem Benutzer nobodyund der Gruppe nogroup: stackoverflow.com/questions/4681067/…

— Taufe

Dies kann auch dadurch verursacht werden, dass auf einen Benutzer verwiesen wird, der nicht vorhanden ist.

— James Mills

18

Ich bin gerade darauf gestoßen und in meinem Fall wurde es durch das Zitieren eines Benutzernamens in meiner Servicedatei verursacht:

[Unit]
Description=Demonstrate Failed at step USER spawning ...: No such process error when user name is quoted

[Service]
User="tadeusz"
ExecStart=/bin/echo hello

[Install]
WantedBy=multi-user.target

Das Starten dieses Dienstes unter Ubuntu 16.04.2 LTS (Amazon EC2-Instanz) schlägt mit folgendem Fehler fehl:

user-example.service: Failed at step USER spawning /bin/echo: No such process

Interessanterweise ist unter Ubuntu Gnome 17.04 (meinem lokalen Computer) die Fehlermeldung viel hilfreicher:

[/etc/systemd/system/user-example.service:5] Invalid user/group name or numeric ID, ignoring: "tadeusz"

Das Entfernen von Anführungszeichen in beiden Umgebungen hat das Problem behoben:

[Service]
User=tadeusz

— Tad Lispy
quelle

1

Vielen Dank. In meinem Fall war der Name völlig falsch, und dies löst dieses Problem für mich sehr gut

— Aleks

1

Nachdem ich 4 Stunden lang an meinen Haaren gezogen hatte, stieß ich auf diesen Beitrag und entfernte ihn, User=tomcatden ich aus dem Blog-Beitrag kopiert hatte. Jetzt funktioniert es gut :)

— Shashanth

Ich habe ein ähnliches Problem, das Korrigieren des Benutzernamens funktioniert nicht, da die Gunicorn-Datei in virtualenv nicht vorhanden ist. Ich habe mit sudo pip3 install gunicorn auf dem AWS EC2 Ubuntu Server installiert. Was könnte ein möglicher Grund sein?

— Reema Parakh

5

Überprüfen Sie, ob der folgende Datensatz in der Konfigurationsdatei von vorhanden ist opendkim:

## Attempt to become the specified user before starting operations. UserID opendkim:opendkim

— user679441
quelle

3

In meinem Fall habe ich versucht, rootals Benutzer und Gruppe zu verwenden.

Ich löschte:

User=root
Group=root

— jmunsch
quelle

2

Für mich war es ein einfaches Problem, den falschen Benutzernamen zu verwenden. Bestätigen Sie, dass Sie den richtigen Benutzer verwenden [Service] User=tadeusz

Laden Sie dann Ihr SytemD neu sudo systemctl daemon-reload

— StackEdd
quelle

1

Bei dieser Fehlermeldung stellte sich heraus, dass ich "User = root", aber nicht "Group = xx" angegeben habe. Als ich beide angegeben habe, wurde Folgendes behoben:

User=root
Group=root

Das Hinzufügen Group=rootoder Entfernen von Benutzer und Gruppe, wie in der Antwort von jmunsch vorgeschlagen, wurde behoben. Es gab eine Art Verzeichnisberechtigungsproblem ohne Angabe der Gruppe.

Ich denke, wenn Sie einen Benutzer angeben, verwendet er nicht die Standardgruppe, von der ich annehme, dass sie auch root ist. Art macht Sinn ...

Update, lief diese Meldung erneut, unabhängig, aber nur beim Booten, manuell gestartet, startete es gut.

Meine Vermutung ist, dass es dadurch verursacht wurde, dass "Active Directory" (in dem diese bestimmte Box einige ihrer Benutzernamen und Gruppen erhält) noch nicht vollständig initiiert wurde

After=vasd.service

Scheint es behoben zu haben, indem es spät genug gestartet wurde. After=mnt-share.mountschien auch das Problem zu umgehen, aber ich denke möglicherweise, weil es einfach "lange genug warten" oder so.

systemctl status xxx sagte:

Process: 5017 ExecStart=/home/user/bin/xx (code=exited, status=217/USER)

Unabhängig von der Meldung ist es auch hilfreich, nach journalctlProtokollen oder Hinweisen darauf zu suchen, was möglicherweise schief gelaufen ist. Wenn es "217 / USER" ist, wird dort nicht viel für die Diagnose angezeigt, aber für alles andere kann es super hilfreiche Informationen enthalten.

— Rogerdpack
quelle

0

Für mich wurde diese Fehlermeldung dadurch verursacht, dass SystemD nach dem Aktualisieren von systemd nicht neu geladen wurde. Führen Sie # systemctl daemon-reloadIhren Computer aus oder starten Sie ihn neu.

— Babken Vardanyan
quelle

1

sudo systemctl daemon-reloadsollte reichen

— dvska