qcontrol und systemd failed, dead, inactive, kotz ;)

[Drache]

Hi,

tl;dr Was läuft beim Start von qcontrol und qcontrold schief, dass ich die Dienste manuell starten muss?

nehmt mir die Überschrift nicht übel aber ich hadere mal wieder mit den Diensten und habe keine Ahnung wo ich ansetzten soll, auch weil ich nicht verstehe was eigentlich das Problem von meinem kleinem süßen qcontrol ist

Es fängt damit an, dass es nun qcontrold und qcontrol unter services gibt…

Code: Alles auswählen

# service qcontrold status
● qcontrold.service - LSB: Start qcontrol daemon
   Loaded: loaded (/etc/init.d/qcontrold; generated; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

aber wunderbarerweise laufen beide nicht

Code: Alles auswählen

# service qcontrol status
● qcontrol.service - LSB: Change status leds for QNAP Turbo Station devices
   Loaded: loaded (/etc/init.d/qcontrol; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-06-30 20:21:43 CEST; 4min 23s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2138 ExecStart=/etc/init.d/qcontrol start (code=exited, status=255)

Jun 30 20:21:43 nasque systemd[1]: Starting LSB: Change status leds for QNAP Turbo Station devices...
Jun 30 20:21:43 nasque qcontrol[2138]: System boot completed.
Jun 30 20:21:43 nasque qcontrol[2138]: Error connecting to socket: No such file or directory
Jun 30 20:21:43 nasque systemd[1]: qcontrol.service: Control process exited, code=exited status=255
Jun 30 20:21:43 nasque systemd[1]: Failed to start LSB: Change status leds for QNAP Turbo Station devices.
Jun 30 20:21:44 nasque systemd[1]: qcontrol.service: Unit entered failed state.
Jun 30 20:21:44 nasque systemd[1]: qcontrol.service: Failed with result 'exit-code'.

Ausprobiert:

Code: Alles auswählen

# /etc/init.d/qcontrol stop
[ ok ] Stopping qcontrol (via systemctl): qcontrol.service.

super das geht, also wieder starten:

Code: Alles auswählen

# /etc/init.d/qcontrol start
[....] Starting qcontrol (via systemctl): qcontrol.serviceJob for qcontrol.service failed because the control process exited with error code.
See "systemctl status qcontrol.service" and "journalctl -xe" for details.
 failed!

Code: Alles auswählen

# systemctl status qcontrol.service 
● qcontrol.service - LSB: Change status leds for QNAP Turbo Station devices
   Loaded: loaded (/etc/init.d/qcontrol; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-06-30 20:29:01 CEST; 1min 9s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2259 ExecStart=/etc/init.d/qcontrol start (code=exited, status=255)

Jun 30 20:29:01 nasque systemd[1]: Starting LSB: Change status leds for QNAP Turbo Station devices...
Jun 30 20:29:01 nasque qcontrol[2259]: System boot completed.
Jun 30 20:29:01 nasque qcontrol[2259]: Error connecting to socket: No such file or directory
Jun 30 20:29:01 nasque systemd[1]: qcontrol.service: Control process exited, code=exited status=255
Jun 30 20:29:01 nasque systemd[1]: Failed to start LSB: Change status leds for QNAP Turbo Station devices.
Jun 30 20:29:01 nasque systemd[1]: qcontrol.service: Unit entered failed state.
Jun 30 20:29:01 nasque systemd[1]: qcontrol.service: Failed with result 'exit-code'.

Das geht also nicht, ich weiß nicht wieso: wenn ich wie vorgeschlagen in Status bzw. Journal nachsehe steht da ungefähr das selbe, wie oben auch schon.

Interessanterweise habe ich inzwischen herausgefunden, dass ich zuerst(!) qcontrold über init.d stoppen muss, dann qcontrold darüber starten kann und dann qcontrol ebenso aus und schließlich erfolgreich anschalten kann. Für mich stellt sich nun die Frage, wie schaffe ich es, dass das System das alleine macht?? Das killen der Dienste muss wegen mir gar nicht sein, die Prozesse so zu starten, dass das danach läuft würde mir reichen

[smutbert]

Vorrausschicken möchte ich, dass ich keine Ahnung habe was qcontrol ist, aber vielleicht macht das ja gar nichts:

An deinen Ausgaben sieht man, dass systemd zwei "Kompatibilitäts-service-Units" erzeugt, die eigentlich nur die beiden Startskripte (»/etc/init.d/qcontrol[d]«) ausführt.
Das Statskript beendet sich nach alter Manier wieder, daher laufen die Dienste aus Sicht von systemd nicht. Zumindest ein Problem gibt es allerdings offensichtlich trotzdem, das Startskript von qcontrol beendet sich mit dem Fehlerstatus 255, es scheitert also offensichtlich.


Ich würde mich aber gar nicht weiter damit beschäftigen woran das Startskript scheitert, sondern vielmehr die Startskripte durch Service-Units ersetzen. In den aktuellen Upstreamquellen findet man die bereits:


»/etc/systemd/system/qcontrol.service«

Code: Alles auswählen

[Unit]
Description=qcontrol
# If the config file is there, we assume qcontrol works on this machine.
ConditionPathExists=/etc/qcontrol.conf

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/sbin/qcontrol statusled greenon
ExecStart=/usr/sbin/qcontrol powerled on
ExecStart=/usr/sbin/qcontrol buzzer short
ExecStop=/usr/sbin/qcontrol buzzer short
ExecStop=/usr/sbin/qcontrol statusled redon
ExecStop=/usr/sbin/qcontrol powerled 1hz

[Install]
WantedBy=multi-user.target

»/etc/systemd/system/qcontrold.service«

Code: Alles auswählen

[Unit]
Description=qcontrold
Requires=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
After=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device

# oder (aus einem Patch des arch-Pakets)
#Requires=sys-devices-platform-gpio\x2dkeys-input-input0-event0.device
#After=sys-devices-platform-gpio\x2dkeys-input-input0-event0.device

# If the config file is there, we assume qcontrol works on this machine.
ConditionPathExists=/etc/qcontrol.conf

[Service]
ExecStart=/usr/sbin/qcontrol -f

(keine Ahnung welchen Zweck die alternativen After- und Requires-Zeilen haben, die ich im arch AUR gefunden habe, aber besonders bei systemd habe ich mich schon öfter an arch orientiert und das hat sich meistens ausgezahlt... - es ist also vielleicht durchaus einen Versuch wert die oberen beiden After und Require auszukommentieren und stattdessen die unteren beiden scharf zu schalten.)

und einen Socket gibt es auch noch - der ist kann imho aber nur notwendig sein, wenn man weiß das ist und, dass man es braucht:

»/etc/systemd/system/qcontrold.socket«

Code: Alles auswählen

[Socket]
ListenStream=/run/qcontrol.sock

[Install]
WantedBy=sockets.target

Wenn ich mich jetzt nicht vertue sollte systemd nach dem Anlegen dieser Dateien beim nächsten Systemstart automatisch diese Units verwenden und die Startskripte ignorieren.
Danach sollte das mit dem Status der Dienste in systemd deutlich übersichtlicher und die Fehlersuche zweifelsfalls einfacher sein...

[Drache]

Hallo Smutbert,

vielen Dank erst einmal. qcontrol ist für das Abfangen von Tasten-Eingaben / Lüftungssteuerung / LED-Steuerung usw. an einem QNAP-NAS zuständig.

Die erste Variante (ohne Patch) führt erstmal zu dem selben Endergebnis …


Fehlermeldungen in qcontrol.service (die hat es jetzt also gleich verwendet)

Code: Alles auswählen

● qcontrold.service
   Loaded: loaded (/etc/systemd/system/qcontrold.service; static; vendor preset: enabled)
   Active: inactive (dead)

Jun 30 22:39:20 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:1] Assignment outside of section. Ignoring.
Jun 30 22:39:20 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:2] Assignment outside of section. Ignoring.
Jun 30 22:39:20 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:3] Assignment outside of section. Ignoring.
Jun 30 22:39:20 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:10] Assignment outside of section. Ignoring.

Die zweite Variante mit Patch

Code: Alles auswählen

Jun 30 22:41:41 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:7] Assignment outside of section. Ignoring.
Jun 30 22:41:41 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:10] Assignment outside of section. Ignoring.
Jun 30 22:41:41 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:1] Assignment outside of section. Ignoring.
Jun 30 22:41:41 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:6] Assignment outside of section. Ignoring.
Jun 30 22:41:41 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:7] Assignment outside of section. Ignoring.
Jun 30 22:41:41 nasque systemd[1]: [/etc/systemd/system/qcontrold.service:10] Assignment outside of section. Ignoring.

Der Pfad der eigentlich angelegt wird, ist

/dev/input/by-path/platform-gpio-keys-event und das hat einen link auf ../event0

ls -l /dev/input/by-path/platform-gpio-keys-event
lrwxrwxrwx 1 root root 9 Jun 30 22:37 /dev/input/by-path/platform-gpio-keys-event -> ../event0


Was nun Assignment outside of section zu bedeuten hat, weiß ich wiederum nicht, muss erst mal suchen…

Danke schonmal ich seh mal weiter

[smutbert]

Irgendwie ist mir beim kopieren die erste Zeile abhanden gekommen, also das [unit] - hab es korrigiert.

[Drache]

Ich bedanke mich mal wieder für deine Mühe. Allein das Ergebnis bleibt sich gleich…

Code: Alles auswählen

systemctl status qcontrold.service 
● qcontrold.service - qcontrold
   Loaded: loaded (/etc/systemd/system/qcontrold.service; static; vendor preset: enabled)
   Active: inactive (dead)
root@nasque:/home/ben# systemctl status qcontrol.service 
● qcontrol.service - qcontrol
   Loaded: loaded (/etc/systemd/system/qcontrol.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Versuch qcontrol einfach so zu starten bringt:

Code: Alles auswählen

-- Unit qcontrol.service has begun starting up.
Jul 01 20:20:15 nasque qcontrol[1504]: Error connecting to socket: No such file or directory
Jul 01 20:20:15 nasque systemd[1]: qcontrol.service: Main process exited, code=exited, status=255/n/a
Jul 01 20:20:15 nasque systemd[1]: Failed to start qcontrol.
-- Subject: Unit qcontrol.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit qcontrol.service has failed.
-- 
-- The result is failed.
Jul 01 20:20:15 nasque systemd[1]: qcontrol.service: Unit entered failed state.
Jul 01 20:20:15 nasque systemd[1]: qcontrol.service: Failed with result 'exit-code'.

Die socket Datei habe ich aber auch übernommen, vielleicht sollte ich die löschen?

Wenn ich dagegen qcontrold anstupse, kommt am Ende das:

Code: Alles auswählen

Jul 01 20:20:15 nasque systemd[1]: qcontrol.service: Failed with result 'exit-code'.
Jul 01 20:23:28 nasque systemd[1]: dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device: Job dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device/start timed out.
Jul 01 20:23:28 nasque systemd[1]: Timed out waiting for device dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device.
-- Subject: Unit dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device has failed.
-- 
-- The result is timeout.
Jul 01 20:23:28 nasque systemd[1]: Dependency failed for qcontrold.
-- Subject: Unit qcontrold.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit qcontrold.service has failed.
-- 
-- The result is dependency.
Jul 01 20:23:28 nasque systemd[1]: qcontrold.service: Job qcontrold.service/start failed with result 'dependency'.
Jul 01 20:23:28 nasque systemd[1]: dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device: Job dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device/start failed with result 'timeout'.

Auch mit der Patch-Variante geht es nun nicht mehr…

Derzeit kriege ich qcontrol also gar nicht mehr lebendig

[smutbert]

qcontrol kümmert sich offensichtlich ohnehin nur um optische (LED) und akustische Rückmeldungen - das würde ich einmal ignorieren, obwohl es vielleicht sogar leichter zu lösen wäre als das mit qcontrold....

Die socket Datei habe ich aber auch übernommen, vielleicht sollte ich die löschen?

Eigentlich dachte ich nicht, dass die probleme verursachen kann, aber einen Versuch ist es wert.

Beim nachträglichen Versuch qcontrold zu starten scheitert es dagegen am Nichtvorhandensein der Gerätedatei. Die fehlenden systemd-Units sind übrigens ein Bug 781886, der angeblich vor mehr als zwei Jahren gefixt wurde, aber in den aktuellen stretch-Paketen fehlen die units soweit ich gesehen habe trotzdem noch.
Möglicherweise gibt es mit dem Programm noch weitere Probleme?

Jedenfalls könntest du wie im Bugreport erwähnt außerdem die Requires und After durch folgendes ersetzen (Wieso wants statt requires weiß ich nicht - vermutlich spielt es keine große Rolle):

Code: Alles auswählen

Wants=systemd-udev-settle.service
After=systemd-udev-settle.service

ist zwar weniger schön, könnte aber (zuverlässiger) funktionieren.

[Drache]

Sorry ich schon wieder,
läuft leider immer noch nicht. Immerhin ich habe mal wieder eine neue Spur:

Es heißt da
Error connecting to socket: No such file or directory

und tatsächlich ist die Datei nicht da. Nun ist die Frage wo käme die her?

Code: Alles auswählen

● qcontrol.service - qcontrol
   Loaded: loaded (/etc/systemd/system/qcontrol.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2017-07-03 22:07:03 CEST; 7s ago
  Process: 1639 ExecStart=/usr/sbin/qcontrol statusled greenon (code=exited, status=255)
 Main PID: 1639 (code=exited, status=255)

Jul 03 22:07:03 nasque systemd[1]: Starting qcontrol...
Jul 03 22:07:03 nasque qcontrol[1639]: Error connecting to socket: No such file or directory
Jul 03 22:07:03 nasque systemd[1]: qcontrol.service: Main process exited, code=exited, status=255/n/a
Jul 03 22:07:03 nasque systemd[1]: Failed to start qcontrol.
Jul 03 22:07:03 nasque systemd[1]: qcontrol.service: Unit entered failed state.
Jul 03 22:07:03 nasque systemd[1]: qcontrol.service: Failed with result 'exit-code'.

[smutbert]

Eigentlich dachte ich, dass die qcontrol selbst erstellt. Eventuell komme ich am Wochenende dazu mir das ganze etwas genauer anzusehen.

[smutbert]

So, jetzt habe ich mir das Debianpaket heruntergeladen und das init-Skript angesehen. Leider ist dabei nicht viel herausgekommen: So wie es aussieht tut auch das init-Skript weiter nichts besonderes - es legt vor allem keine socket-Datei oder irgendso etwas an.

Mir fällt dazu nur noch ein es doch mit einer zusätzlichen qcontrold.socket zu versuchen

Code: Alles auswählen

[Socket]
ListenStream=/run/qcontrol.sock

[Install]
WantedBy=sockets.target

die aber auch eingelesen und aktiviert werden muss

Code: Alles auswählen

# systemctl daemon-reload
# systemctl enable qcontrold.socket

aber es würde mich fast wundern, wenn das wirklich hilft...

[Drache]

Hallo Smutbert,

Letzter Stand: ich muss inzwischen nur noch einmal nach jedem Start

Code: Alles auswählen

systemctl restart qcontrol

eingeben, dann läuft das ganze wie erwartet. Ob sich das über systemd automatisieren lässt, wäre jetzt noch interessant, ansonsten schau ich mal ob ich es mit cron geflickt bekomme.

[smutbert]

Das klingt finde ich schon ein bisschen besser, vor allem wenn du wirklich qcontrol und nicht qcontrold (?) meinst.

Was kommt denn jetzt bei

Code: Alles auswählen

# journalctl -p 7 -u qcontrol
# journalctl -p 7 -u qcontrold

heraus?
Mir ist auch noch nicht ganz klar ob qcontrol.service schon den laufenden daemon, also qcontrold.service braucht um die Einstellungen vorzunehmen oder nicht (und vielleicht sogar ganz im Gegenteil sich mit einem bereits laufenden daemon ins Gehege kommt).

[Drache]

Nee, is tatsächlich qcontrol … also ohne d.


das journal zu qcontrold:

Code: Alles auswählen

-- Logs begin at Thu 2017-07-20 08:48:21 CEST, end at Thu 2017-07-20 19:51:20 CEST. --
Jul 20 08:48:38 nasque systemd[1]: Started qcontrold.
Jul 20 08:48:39 nasque qcontrol[350]: qcontrol 0.5.5 daemon starting.
Jul 20 08:48:39 nasque qcontrol[350]: Register evdev on /dev/input/by-path/platform-gpio-keys-event
Jul 20 08:48:39 nasque qcontrol[350]: confdir: loading from /etc/qcontrol.d...
Jul 20 08:48:39 nasque qcontrol[350]: server already running
Jul 20 08:48:39 nasque qcontrol[350]: Error accepting connection: Bad file descriptor
Jul 20 08:48:39 nasque systemd[1]: Started qcontrold.
Jul 20 08:48:39 nasque qcontrol[354]: qcontrol 0.5.5 daemon starting.
Jul 20 08:48:39 nasque qcontrol[354]: Register evdev on /dev/input/by-path/platform-gpio-keys-event
Jul 20 08:48:39 nasque qcontrol[354]: confdir: loading from /etc/qcontrol.d...
Jul 20 09:53:56 nasque qcontrol[354]: ts209: setting fan to "full"
Jul 20 09:54:09 nasque qcontrol[354]: ts209: setting fan to "silence"
Jul 20 09:54:11 nasque qcontrol[354]: ts209: setting fan to "full"

sieht sich so aus, als ob qcontrold (trotz eines Errors) qcontrol startet und das läuft dann auch erst mal …

dagegen das log zu qcontrol

Code: Alles auswählen

-- Logs begin at Thu 2017-07-20 08:48:21 CEST, end at Thu 2017-07-20 19:51:20 CEST. --
Jul 20 08:48:35 nasque systemd[1]: Starting qcontrol...
Jul 20 09:19:33 nasque systemd[1]: qcontrol.service: Main process exited, code=killed, status=15/TERM
Jul 20 09:19:33 nasque systemd[1]: Stopped qcontrol.
Jul 20 09:19:33 nasque systemd[1]: qcontrol.service: Unit entered failed state.
Jul 20 09:19:33 nasque systemd[1]: qcontrol.service: Failed with result 'signal'.
Jul 20 09:19:33 nasque systemd[1]: Starting qcontrol...
Jul 20 09:19:33 nasque systemd[1]: Started qcontrol.

MIt "Failed with result 'signal'" kann ich leider nichts anfangen.

Was mich etwas irritiert sind die Zeitstempel: Demnach scheint qcontrol nämlich fast eine halbe Stunde problemlos zu laufen. Es blinkt aber fortwährend die LED rot-grün und das Gerät gibt keinen Signalton aus. Das ändert sich erst mit dem restart zum richtigen Verhalten.

[smutbert]

Was mir auffällt ist, dass qcontrol ein paar Sekunden vor qcontrold gestartet wird - möglicherweise sollte qcontrold also bereits laufen, wenn qcontrol gestartet wird.

Ich würde es dementsprechend mit diesen Zeilen in qcontrol.service versuchen

Code: Alles auswählen

[Unit]
...
Requires=qcontrold.service
After=qcontrold.service

...

[Drache]

Tja, noch gehts leider nicht automatisch.

Inzwischen sieht das Ergebnis so aus …

Code: Alles auswählen

systemctl status qcontrol
● qcontrol.service - qcontrol
   Loaded: loaded (/etc/systemd/system/qcontrol.service; enabled; vendor preset:
   Active: activating (start) since Wed 2017-07-26 19:41:33 CEST; 14min ago
 Main PID: 342 (qcontrol)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/qcontrol.service
           └─342 /usr/sbin/qcontrol statusled greenon

Jul 26 19:41:33 nasque systemd[1]: Starting qcontrol...

Startet notfalls also auch stundenlang

Hat es vielleicht was mit diesem Type:oneshot zu tun?

[smutbert]

oneshot sagt, dass hier nur ein Programm ausgeführt wird, das ein paar Dinge erledigt und das sich danach wieder beendet - im Gegensatz zu einem Daemon, der gestartet wird und von da an laufen soll und falls er sich beendet von neuem gestartet wird.

Das Programm qcontrol sollte offensichtlich grundsätzlich beides machen. Einmal soll es von qcontrold.service als Daemon gestartet werden und einmal soll es von qcontrol.service aus gestartet nur ein paar LED- und Beep-Einstellungen vornehmen. Ich weiß nur nicht ob der Daemon für letzteres bereits laufen soll oder nicht oder ob es sogar egal ist.
Die Reihenfolge der beiden ist momentan auch das einzige was mir als mögliche Fehlerursache von qcontrol.service einfallen will, denn qcontrol funktioniert ja offensichtlich grundsätzlich - sowohl als Daemon wie auch als nachträglich gestartetes normales Programm.

(Weil das nachträgliche Starten funktioniert bin ich auch davon ausgegangen, dass es den Daemon braucht bzw. dass der Daemon zumindest nicht stört, aber die zusätzliche Abhängigkeit hat ja offensichtlich auch nicht geholfen...)

Hier hängt es außerdem bereits offensichtlich am ersten Befehl der von qcontrol.service gestartet wird - das ist merkwürdig und ich bin ratlos.

[FalconHG]

Ich hatte bei mir heute ein ähnliches Problem nach dem Upgrade von Jessie auf Stretch mit den gleichen Fehlermeldungen. Geholfen hat am Ende die vollständige Deinstallation mittels:

Code: Alles auswählen

apt-get --purge remove qcontrol

Danach neu installiert und seitdem läuft es.

[Anakim]

ich hatte das gleiche Problem.
Falls du noch interesse hast hier gibt's eine Lösung

alles was du hier eingstellt hast löschen -> nix für ungut und dann das hier machen

Code: Alles auswählen

tim@mars:~$ sudo apt-get install insserv
tim@mars:~$ sudo insserv qcontrold,start=S,2,3,4,5

Although Debian 9 uses systemd, the qcontrol package still uses System V init scripts.

For packages that have System V init scripts, systemd will use systemd-sysv-generator to generate suitable systemd unit files.

If you have a look in /run/systemd/generator.late you'll find both a qcontrol.service and qcontrold.service, but only qcontrol.service is linked to targets (look under the graphical.target.wants and multi-user.target.wants subdirectories).

I tried to use sudo update-rc.d qcontrold enable however because some links already exist it refuses to do anything. Apparently it uses insserv under the hood and I was able to successfully use that to make things right.

Hope this helps!

Ich musste bei mir noch folgendes machen

 Ich habe noch die qcontrold.service in /lib/system/system angepasst

Code: Alles auswählen

[Unit] 
Description=qcontrold 
#Requires=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device 
#After=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device 
# If the config file is there, we assume qcontrol works on this machine. 
ConditionPathExists=/etc/qcontrol.conf 

[Service] 
ExecStart=/usr/sbin/qcontrol -f 

[Install] 
WantedBy=multi-user.target 

Die Requieres und After haben den start verhindert

https://forum.qnap.com/viewtopic.php?f=147&t=136192