debian testing (jessie) inputlirc startet nicht

HI - ich hab inputlic installiert, über /etc/default/inputlirc entsprechend konfiguriert.

weder ein /etc/init.d/inputlirc noch ein systemctl start inpiutlirc startet den daemon.

Wenn ich in /etc/init.d/inputlir die Zeile

...
. /lib/lsb/init-functions
...

auskommentiere, startet inputlirc - allerdings auch nicht über den systemstart - da hilft auch kein insserv inputlirc - ich hab irgendwie den Verdacht, dass mir systemd einen Strich durch die Rechnung macht...

interessant - bei sieht das so aus:

root@kodi1:/etc/systemd/system# systemctl status inputlirc -l
● inputlirc.service - LSB: Start inputlirc daemon
   Loaded: loaded (/etc/init.d/inputlirc)
   Active: active (exited) since So 2015-02-01 12:55:31 CET; 43min ago


Feb 01 12:55:31 kodi1 inputlirc[599]: Starting inputlirc
Feb 01 12:55:31 kodi1 inputlirc[599]: inputlircd: Could not open /dev/input/irremote0: No such file or directory
Feb 01 12:55:31 kodi1 inputlirc[599]: Unable to open any event device!

wobei ein ls -l /dev/input/i liefert:

root@kodi1:/etc/systemd/system# ls -l /dev/input/
insgesamt 0
drwxr-xr-x 2 root root      60 Feb  1 12:55 by-id
drwxr-xr-x 2 root root     100 Feb  1 12:55 by-path
crw-rw---- 1 root input 13, 64 Feb  1 12:55 event0
crw-rw---- 1 root input 13, 65 Feb  1 12:55 event1
crw-rw---- 1 root input 13, 66 Feb  1 12:55 event2
crw-rw---- 1 root input 13, 67 Feb  1 12:55 event3
crw-rw---- 1 root input 13, 68 Feb  1 12:55 event4
crw-rw---- 1 root input 13, 69 Feb  1 12:55 event5
crw-rw---- 1 root input 13, 70 Feb  1 12:55 event6
crw-rw-r-- 1 root input 13, 71 Feb  1 12:55 event7
crw-rw---- 1 root input 13, 72 Feb  1 12:55 event8
lrwxrwxrwx 1 root root       6 Feb  1 12:55 irremote0 -> event7
crw-rw---- 1 root input 13, 63 Feb  1 12:55 mice
crw-rw---- 1 root input 13, 32 Feb  1 12:55 mouse0
root@kodi1:/etc/systemd/system#

nachdem ich gerade noch eine Verzweiflungstat beging so : (Ich hatte in allen Configs irremote0 durch remote ersetzt - ändert aber nichts.

# Options to be passed to inputlirc.
#EVENTS="/dev/input/event*"
#EVENTS="/dev/input/irremote0"
EVENTS="/dev/input/remote"
#OPTIONS=
OPTIONS="-m0 -g -c"

per udev-regel:

SUBSYSTEM=="input",ATTRS{idVendor}=="1784",ATTRS{idProduct}=="0011",SYMLINK="input/remote"

wenn ich von hand starte mit der auskommentierten Zeile in inputlirc unter /etc/init.d , dann tuts ja auch - also der Device-Eintrag kann so grob falsch nicht sein.

Hab ich es mit chroot-Umgebung zu tun?

so - bin jetzt etwas weiter.

Das ganze hängt an einem timing-problem. Ich hab /usr/sbin/inputlircd durch ein shell-script ersetzt:

#! /bin/bash
{
   echo $#, $@
   set
   env
   ls -l /dev/input/remote
   ls -ld /var/run/lirc
   ls -l /var/run/lirc
   strace /usr/sbin/inputlircd.org $@
} >> /tmp/inputlircd.log 2>&1

Das Log enthält beim systemstart dann:

...
BASH_VERSION='4.3.30(1)-release'
DIRSTACK=()
EUID=0
GROUPS=()
HOSTNAME=kodi1
HOSTTYPE=x86_64
IFS=$' \t\n'
LANG=de_DE.UTF-8
MACHTYPE=x86_64-pc-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PIPESTATUS=([0]="0")
PPID=596
PS4='+ '
PWD=/
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=1
TERM=dumb
UID=0
_=/dev/input/remote
_SYSTEMCTL_SKIP_REDIRECT=true
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=de_DE.UTF-8
SHLVL=1
_SYSTEMCTL_SKIP_REDIRECT=true
_=/usr/bin/env
ls: Zugriff auf /dev/input/remote nicht möglich: Datei oder Verzeichnis nicht gefunden
drwxr-xr-x 2 root root 40 Feb  6 08:19 /var/run/lirc
insgesamt 0
execve("/usr/sbin/inputlircd.org", ["/usr/sbin/inputlircd.org", "-c", "-m", "0", "-g", "/dev/input/remote"], [/* 6 vars */]) = 0
....

Mit anderen Worten - /dev/input/remote ist noch nicht da, wenn inputlircd gestartet werden solll.

Das komische für mich ist dann allerdings ein Verhalten des systemd. Kiste also hochgefahren, inputlird geht schief weil device noch nicht da. systemctl start inputlirc tut nun aber so, als gäbe es nochts zu tun. Ein systemctl stop inputlirc und ein systemctl start inputlirc bringen dan inputlirc dann hoch. Irgendwie komisch das ganze Thema systemd.

Was ich aber nicht verstehe, warum ist inputlircd zu schnell - denn eigentlich sollte er ja auf udev warten:oder etwa nicht?

...
#! /bin/sh
### BEGIN INIT INFO
# Provides:          inputlirc
# Required-Start:    $remote_fs 
# Required-Stop:     $remote_fs
# Should-Start:      $syslog udev lirc
# Should-Stop:       $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start inputlirc daemon
### END INIT INFO
...
. /lib/lsb/init-functions


{code]


EDIT: Es geht um eine Sekunde!!!1 - mit folgender Änderung (Warteschleife auf /dev/input/remote) in /etc/init.d/inputlirc - startet es:


[code]
#! /bin/sh
### BEGIN INIT INFO
# Provides:          inputlirc
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Should-Start:      $syslog udev lirc
# Should-Stop:       $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start inputlirc daemon
### END INIT INFO


{
while [ ! -L /dev/input/remote ]; do
    date
    sleep 1
done
} >> /tmp/inputlirc.log 2>&1


. /lib/lsb/init-functions


DAEMON="/usr/sbin/inputlircd"
NAME="inputlirc"
DESC="inputlirc"
....

im entsprechenden Log ist aber nur ein Timestamp drin - mit anderen worten - inputlircd wird eine Sekunde zu früh gestartet...
Das System läuft auf ner SSD vom Einschalten bis zum Kodi-Logo in nur 15 Sekunden - und da sind noch sleeps drin....

Ist doch aber murks, dass man die Abhängigkeiten zwischen udev und inputlirc offensichtlich SO wie im Originalzustand geliefert nicht nutzen kann...

Mein System ist zu schnell - deins zu langsam ;-P
bzw. die Abhängigkeiten der STartreihen folge(n) sind unsauber. implementiert (im Standard)

K.A. der erste Eindruck des Systemd bei mir ist allerdings nicht gut.

Ich fühlte mich mal kurz an Windows erinnert - das ganze war/ist so obskur geregelt, dass man zunächst mal an sich zweifelt - ich hatte z.B. an der /etc/default/inputlirc Änderungen vorgenommen - die zogen aber erst nach einem stop (eeines Dienstes der NICHT lief und einem weiteren start)....

Desweiteren plage ich mich noch damit rum, dass ich gdm nocht abgeschaltet bringe - ich würde gerne startx über die inittab loslaufen lassen - aber weder hilft es, systemctl disable gdm... zu machen, noch ein insserv -r

Ich sach ja nicht, dass früher alles besser war aber gefühlt ist das alles etwas fett aufgetragen für ganz einfache Aufgaben und scheitert dennoch...

Warten ist sicher falsch - das mach ich auch nicht freiwillig.

Wenns eine bessere Lösung gibt - gerne her damit. Ich hätte eigentlich erwartet, dass die Abhängigkeit von udev ausreicht - sonst macht die Definition als solches ja schon keinen Sinn.

Das ganze timing der Skripte zum Systemstart ist aber aus dem Takt.... Netzwerkkonfiguration ist auch zu langsam (gewesen) .... kodi nutzt bei mir eine zentrale mysql-Datenbank - der hostname wird über nen dns aufgelöst. nachdem per dhcp das Netzwerk der Büchse konfiguriert ist (das ging auch mal gut und mal gings in die Hose...) Es ging auch da um Bruchteile von Sekunden...

Als aktuelles Fazit muss ich sagen, dass die zentrale Aufgabe nicht ordentlich gelöst ist durch systemd (zumindest nicht mit den default-skripts) der beteiligten Komponenten