it-swarm.com.de

Was bedeutet "Fehler beim Ausführen der Operation: Ungültiges Argument", wenn systemctl enable ausgeführt wird?

Ich habe eine systemd-Dienstdatei erstellt (speziell für svnserve; ich verwende das Beispiel hier https://stackoverflow.com/a/40584047/464087 ), und wenn ich es aktiviere, tippe ich

Sudo systemctl enable svnserve

Ich bekomme die Antwort 

Failed to execute operation: Invalid argument

Laufen 

Sudo systemctl status svnserve

erträge

● svnserve.service - Subversion protocol daemon
   Loaded: loaded (/etc/systemd/system/svnserve.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

ich habe keine Ahnung, dass irgendetwas falsch ist. Ich kann den Dienst dann ohne Fehler starten, und er scheint wie erwartet zu laufen. Nach dem Starten des Systemctl-Status bekomme ich immer noch keine Ahnung, dass irgendetwas falsch ist:

● svnserve.service - Subversion protocol daemon
   Loaded: loaded (/etc/systemd/system/svnserve.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-01-09 22:10:14 UTC; 6s ago
  Process: 9677 ExecStart=/usr/bin/svnserve $DAEMON_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 9678 (svnserve)
    Tasks: 1
   Memory: 964.0K
      CPU: 2ms
   CGroup: /system.slice/svnserve.service
           └─9678 /usr/bin/svnserve --daemon --pid-file /run/svnserve/svnserve.pid --root /srv/svn/repos --log-file /var/log/svnserve/svnserve.log

Was bedeutet diese Fehlermeldung? Und auf welcher Ebene soll "ungültiges Argument" gelten? Ein Argument für den Befehl svnserve? Eine Eigenschaft in der Servicedatei? Ein Befehlszeilenargument für den Befehl servicectl selbst?

FWIW befindet sich auf einem Ubuntu 16.04 LTS-Server.

6
EricS

Ich hatte einen ähnlichen Fall. In meinem Fall ging das Problem nach dem Entfernen der Alias-Zeile aus dem Abschnitt [Install] weg. Dank an Anton in einem anderen Thread: https://stackoverflow.com/a/34978908/2711456 - Der Aliasname stimmt möglicherweise nicht mit dem Servicenamen überein.

8
T .

Ich habe genau das gleiche erlebt. Das Löschen von "Alias" funktioniert, aber tatsächlich kann der Alias ​​den gleichen Namen wie die Servicedatei haben.

Der Grund, warum es nicht funktioniert, hängt mit dem Verzeichnis zusammen, in dem die Servicedatei abgelegt wird. 

Systemd enable erstellt einen Alias ​​im Verzeichnis "/ etc/systemd/system" und im Zielverzeichnis, das diesen Dienst wünscht. Wenn sich die ursprüngliche Servicedatei bereits in "/ etc/systemd/system" befindet, kann der Alias ​​nicht erstellt werden, wenn systemd versucht, diesen Service zu aktivieren. 

Die Lösung legt die Servicedatei im Verzeichnis "/ lib/systemd/system /" ab und funktioniert.

2
blackpiglet

sie versuchen es, ich wurde es gelöst:

  1. cd /etc/systemd/system/multi-user.target.wants

  2. ls

  3. suchdienst-Fehler "Fehler beim Ausführen der Operation: Ungültiges Argument"

  4. rm -rf yourname.service

  5. cd/etc/systemd/system /

  6. nano yourname.service

bearbeiten Sie Ihren Content-Service (möglicherweise Ihren Content-Fehler (Überprüfung von Symboy [], ... bla..bla)

==> speichern

  1. systemctl Daemon-Reload

  2. systemctl enable yourname.service

viel Glück!!!

2
Oanh Le Thi

Was ich auch gefunden habe, ist der Fehler mit Kommentaren (zumindest bei systemd 219). Wenn Sie nach einem Code der Servicedatei einen Kommentar hinterlassen haben, kann dieser nicht aktiviert werden. Bringen Sie also einen Kommentar in die neue Zeichenfolge oder entfernen Sie ihn. Ich habe es getestet und es funktioniert für mich:

WantedBy=multi-user.target
# runs in init 3 (multi-user mode for linux)

dieser wird nicht funktionieren:

WantedBy=multi-user.target  # runs in init 3 (multi-user mode for linux)

einige Diskussionen sind hier: https://github.com/rabbitmq/rabbitmq-server/issues/1422

1
Evgeny

Nach der letzten Zeile Ihrer /etc/systemd/system/youunit.service-Datei ist das CR-Symbol erforderlich . Überprüfen Sie es und entfernen Sie /etc/systemd/system/multi-user.target.wants/youunit.service____. Versuchen Sie dann erneut, systemctl enable youunit.

1
Joe Go

Ich denke, wir haben bereits eine ähnliche Antwort. Ich möchte nur den Grund angeben.

Antworten:

cd /etc/systemd/system/multi-user.target.wants/  # it can be other WantedBy item
ls -lA              # notice that <your>.service is not a link
rm <your>.service   # remove it

Und jetzt versuchen Sie:

Sudo systemctl enable <your>.service

Es sollte den richtigen Link erstellen und Ihren Dienst aktivieren.

0
Andrei