Konfiguration des gpsd

Hinweis: In dem Thema Konfiguration des gpsd gibt es 20 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hi,
    eigentlich ist alles ganz einfach:
    - U-Blox GPS Empfänger mit USB-Anschluss gekauft
    - angesteckt und Infos ausgelesen mit lsusb: ID 1546:01a7 U-Blox AG
    - nachsehen (und wer will etwas nachgetragen in file:///usr/share/usb.ids) (Referenz in man page von lsusb)
    - das Kernel-Modul cdc_acm wurde automatisch geladen (prüfe mit lsmod|grep acm)
    - und im dmesg finden sich die Zeilen:

    Code
    usb 9-5: New USB device found, idVendor=1546, idProduct=01a7
    usb 9-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 9-5: Product: u-blox 7 - GPS/GNSS Receiver
    usb 9-5: Manufacturer: u-blox AG - www.u-blox.com
    [...]
    cdc_acm 9-5:1.0: ttyACM0: USB ACM device
    usbcore: registered new interface driver cdc_acm


    - Das Device file:///dev/ttyACM0 gibt es und es hat die richtigen Berechtigungen.
    - Bei den ersten Bearbeitungsversuchen war das USB-Modul sehr schweigsam.
    Nach einiger Zeit begann es munter grün zu blinken und auch zu texten: cat /dev/ttyACM0
    - Nächste Station auf dem Weg zum Netzwerkdienst zypper install gpsd
    - minimalistisches Starten des daemons gpsd /dev/ttyACM0
    - mit Kontroll-Socket und explizit angegebenem Default-port gpsd -F /var/run/gpsd.sock -S 2947 -G /dev/ttyACM0
    - Testen mit Anwendung xgps (im Paket "gpsd-clients")
    - Nachsehen wie der Start lief: netstat -tan und feststellen, dass der Daemon nur ohne {tt]-G[/tt] local und auf IPv4 läuft:
    tcp 0 0 127.0.0.1:2947 0.0.0.0:* LISTEN  
    und mit -G ist er auch von anderen Systemen abrufbar sowohl über IPv4 wie auch über IPv6:
    tcp 0 0 0.0.0.0:2947 0.0.0.0:* LISTEN  
    tcp 0 0 :::2947 :::* LISTEN
    - Konfigurieren wie man das seit 20 Jahren SuSE eben so macht in file:///etc/sysconfig/gpsd sind 3 Einträge (Kommentare gelöscht)

    Code
    GPSD_STARTBYUDEV="no"                                                                                                                                                                                                                                                         
    GPSD_PORT=
    GPSD_OPTIONS=""


    Hier beginnen meine Problemchen:
    - Ändern von no auf yes, ändert zwar die Datei, ergibt aber keinen Hotplug-Service. Das USB-Gerät wird erkannt, das Kernel-Modul und das tty geladen. Das war es.
    - Also mit rpm -ql gpsd die Dateien des Paketes erfragt:
    - Es gibt wohl den Dienst service mit Dateien unter file:///usr/lib/systemd/system/
    - und den mit "yes" vermeindlich aktivierten Hotplug-dienst uDev unter file:///usr/lib/udev/




    Erster Anlauf mit uDev:


    - in der Datei file:///usr/lib/udev/rules.d/51-gpsd.rules fehlt der passende Eintrag, also aus Unwissenheit, ob ttyUSB* wörtlich zu nehmen ist:

    Code
    # U-Blox AG
    KERNEL=="ttyACM*", ATTR{idVendor}=="1546", ATTR{idProduct}=="01a7", RUN="gpsd.sh"
    KERNEL=="ttyUSB*", ATTR{idVendor}=="1546", ATTR{idProduct}=="01a7", RUN="gpsd.sh"

    - in der vermutlich aufgerufenen Datei file:///usr/lib/udev/gpsd.sh


    + resultiert die Variable DEVNAME vermutlich aus der Übergabe


    + es kann wohl nur ein USB-Device damit gleichzeitig aktiv sein
    - Nach ein bisschen Lesen fällt das Kommando gpsdctl (mit 'd') im Paket auf:

    Code
    # ps ax | grep gps
      861 pts/5    S+     0:00 grep --color=auto gps
    # gpsdctl add /dev/ttyACM0
    # ps ax | grep gps
      864 ?        S<s    0:00 gpsd -F /var/run/gpsd.sock
      867 pts/5    S+     0:00 grep --color=auto gps
    # gpsdctl remove /dev/ttyACM0
    # ps ax | grep gps
      864 ?        S<s    0:00 gpsd -F /var/run/gpsd.sock
      867 pts/5    S+     0:00 grep --color=auto gps

    - Eher ein Streifschuss, denn egal ob in der file;///etc/sysconfig/gpsd auf yes oder no steht, es fehlt der "DEVNAME". Und beenden funktioniert auch nicht.
    - Auskommentieren der beiden Zeilen oben in file:///usr/lib/udev/rules.d/51-gpsd.rules ändert nichts am Ergebnis.



    Nun zum zweiten Anlauf mit service:


    Code
    # /usr/sbin/rcgpsd start
    A dependency job for gpsd.service failed. See 'journalctl -xe' for details.
    # service gpsd start
    A dependency job for gpsd.service failed. See 'journalctl -xe' for details.
    # service gpsd status
    ● gpsd.service - GPS (Global Positioning System) Daemon
       Loaded: loaded (/usr/lib/systemd/system/gpsd.service; disabled; vendor preset: disabled)
       Active: inactive (dead)

    Den in den Dateien erwähnten Dienst chronyd habe ich testweise installiert und gestartet, ohne Änderung am Ergebnis.


    Hier wäre mir eine Hilfestellung recht.


    Ich habe das Gefühl, je nach Distribution und Kalendermonat ändert sich dieser Konfigurationsteil recht stark,
    während die Qualität der Fehlereingrenzung aus meiner Sicht sub omni canone ist (unter jedem Standard/Kanon).


    Wie kann ich den gpsd als Systemdienst im Rahmen der Standard-Installation starten?
    Bitte: Erklären, was wo warum geändert werden muss. (Die Doku werde ich dann trotzdem noch lesen.)

  • Nahezu alle Vermutungen von dir sind falsch.


    Dein Gerät wird korrekt erkannt. Über den USB (UniveralSerialBus) triggert es beim EInstöpseln das UDEV Subsystem, was das Ding auch "erkennt".
    Der Chip erklärt dem Subsystem, dass es ein Modem wäre und als ein ACM - "Modem" (AbstractControlModel) mit dem Linuxkernel reden wird.
    Der lädt auch korrekt den cdc_acm (CommunicationDeviceClassAbstractControlModel).
    (Es sei dahin gestellt, ob das korrekt ist. Tatsache ist, dass viele Hersteller dem Kernel vorgaukeln, ihr Geräte wäre ein Modem. Die eigentliche Kommunikation sieht dann ganz anders aus. Das ist aber billiger, leichter zu implementieren und funktioniert ganz gut. Bei sehr vielen Geräten.)


    Jedenfalls ist dein Gerät einsatzbereit, falls ein Programm korrekt mit ihm reden möchte.
    Mache also deine Rateversuche in den UDEV- Regeln rückgängig. Das gibt nur Ärger, wenn du für ein Gerät zwei (verschiedene) Regeln einträgst. Welche soll den letztlich angewendet werden? Beide zugleich?


    Dass ein GPS Empfänger irgendetwas mit dem Netzwerk - und noch dazu mit IPv4 vs. IPv6 zu tun haben sollte, ist mir völlig schleierhaft.
    Das Gerät selbst ist ein billiger GPS - Empfänger und hat damit garantiert nichts am Hut. Wozu auch?


    systemd ändert sich kaum und arbeitet aus Usersicht schon immer so.
    In /usr/lib solltest du überhaupt nicht rumfuhrwerken. Dort ist Kernelland. Alles, was dort von systemd veranstaltet wird, kann und soll dir egal sein. (Zumal das auch selten ein Update überlebt.) Dort liegen Systemservices und autogenerierte Unitfiles. (Jeder Systemdienst, also jeder Service hat ein Unitfile. Es nennt sich <irgendwas>.service )


    Du kannst für deine Belange alles in /etc/systemd überschreiben, oder neue Services hinzufügen und sogar in deinem Home entsprechende Unitfiles nach Gusto als User starten.
    Du willst dein Gerät unter /etc/systemd haben.


    Wenn schon ein Unitfile mitgeliefert wird, einfach dort rein und ein beherztes systemctl enable <name_deines_gps>.service && systemctl start <name_deines_gps>.service sollte alles sein.
    Mag sein, dass man dieses Serivefile selbst schreiben muss.
    Über das mitgelieferte Shellscript schweigst du dich leider aus. Dort könnte man nachlesen, was das Ding zum Laufen braucht.
    Vielleicht läuft es ja längst - hättest du das System nicht mit deiner Udev- Regel geärgert.


    Wenn dir das nicht weiterhilft, poste das Script.

  • OK, Paket gelöscht (keine der Dateien war mehr da) und neu installiert, dann nach Anleitung versucht:

    Code
    # systemctl enable gpsd.service
    Created symlink from /etc/systemd/system/multi-user.target.wants/gpsd.service to /usr/lib/systemd/system/gpsd.service.
    Created symlink from /etc/systemd/system/sockets.target.wants/gpsd.socket to /usr/lib/systemd/system/gpsd.socket.
    miyamoto:~ # systemctl start gpsd.service
    A dependency job for gpsd.service failed. See 'journalctl -xe' for details.

    Die Unit-Files (es sind 3 Dateien des Pakets im file:///usr/lib/systemd/service/) habe ich gelesen. Deshalb diesen chronyd als mögliche Dependency gestartet.
    Ich habe aber hier KEIN Script geschrieben.



    Die Datei file:///usr/lib/udev/gpsd.sh ist Teil des Paketes gpsd.


    Warum geht das jetzt nicht ?
    Was bedeutet "The result is dependency", bzw. welche ?

  • Die korrekte Modifikation der oben genannten Zeile wäre

    KERNEL=="ttyACM*", ATTR{idVendor}=="1546", ATTR{idProduct}=="01a7", RUN="gpsd.sh"

    Dies entspricht der Dokumentation unter Writing udev rules
    Dort kann auch nachgelesen werden, dass diese Attribute nur bei erfolgreicher AND-Verknüpfung aktiv sind.

  • Und hier hast du nachgelesen, dass du deine UDEV- Regeln löschen sollst.


    Laut deinen Fehlermeldungen ist wohl von deinen Versuchen ein Socketfile übriggeblieben.


    Da du, als Profi, das aber wohl auf deine Weise lösen willst, (und dazu die falschen Seiten im Netz liest), kann ich dir nicht helfen.


    Mein Weg wurde skizziert: Lösche deine Regeln. beseitige alle Relikte deiner gescheiterten Versuche (incl. aller Socketfiles).
    Und einmal, und nur einmal ein enable für das mitgelieferte Servicefile und dann ein start.
    Das System hat kein Problem mit dem Gerät.
    Treiber wurden und werden)längst geladen.


    Willst du doch weiterhin Hilfe, poste nicht irgendwas.
    Wenn wir etwas lesen wollen, dann schreiben wir das schon.
    Die nicht relevaten udevadm Ausgaben kannst dir sparen. Das/die Unitfile(s) wäre viel interessanter.

  • Du hast recht, es waren die falschen Seiten.


    Aber ich glaube, auch die Datei aus dem openSUSE Paket ist an dieser Stelle falsch. Die anderen bei mir installierten Pakete verwenden teilweise die alte Notation ATTR und teilweise die neue Notation ATTRS.
    Da diese Installation schon ein ordentliches Erbe habe (ich glaube das Image wurde als 8.x oder 9.x geboren), sind die anderen Zeilen mit ATTR möglicherweise ererbt und nutzlos.
    In diesem Fall ist die korrekte Syntax für mich sicher diese

    Code
    KERNEL=="ttyACM*", ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7", RUN="gpsd.sh"




    (Die anderen Zeilen in dem Paket müssen eventuell auch entsprechend korrigiert werden.)
    Zur Fehlersuche verwendete ich udevadm test /sys/class/tty/ttyACM0. Das Script gpsd.sh wurde nur in der angegebenen Form, nicht in der alten registriert.
    Nun ist endlich der vollständige Satz der Dateien vorhanden, die ich nach dem Lesen des Skripts erwartet hätte:


    Code: /var/run/gpsd.*
    # ls -lstr /var/run/gpsd.*
    0 srwxr-xr-x 1 root root  0 Feb 27 21:09 /var/run/gpsd.socket
    4 -rw-r--r-- 1 root root 13 Feb 27 21:09 /var/run/gpsd.device
    0 srw------- 1 root root  0 Feb 27 21:09 /var/run/gpsd.sock




    Danke für den Tipp mit dem Socket. Der richtige Socket wird nämlich nur generiert, während das Device angelegt wird.



    Sorry, aber mich bringt das nicht wirklich weiter ... aber vielleicht siehst Du das anders.




    Das gpsd.sh-Skript aus dem Paket soll den Dienst eigentlich starten (dachte ich). Jetzt möchte ich sehen, was wirklich passiert.
    dmesg ist zu knapp, also das system log ansehen während ich das USB-Gerät entferne und 5 Sekunden später wieder einstecke.
    Das Log passt leider nicht mehr hierher (Limit sind 10kB).

  • Habe ich hier gemacht, was Du möchtest ?

  • Habe ich hier gemacht, was Du möchtest ?

    Nein.


    Du sollst alle Udev- Regeln von dir löschen.
    Dann alle evtl. verbliebenen Sockets löschen.


    Ich habe nirgends irgendetwas von Deinstallieren und noch mal installieren geschrieben.
    Das mag unter Windows helfen - ist aber meist völlig sinnlos unter Linux.


    Entweder es liegen noch alte Sockets rum, oder der Service hat keine Rechte dort zu schreiben, oder es läuft bereits ein solcher Service.


    Schön ist das nicht.
    Das Script fuhrwerkt in /usr/lib rum.
    Das sollte keine anständige Installationsroutine tun. Es hat in /etc seinen Job zu erledigen. Aber da solle man den Hersteller anschnauzen.


    Du hast lediglich ein Problem mit dem Socket.
    Also:

    • alle Udev-Regeln von dir löschen
    • Gerät ausstöpseln
    • eventuell laufende GPS Services stoppen systemctl stop <gps-dingens>.service
    • alle verbliebenen Sockets dieses Geräts stoppen.
    • Sicherstellen, dass der Dienst auch in das Socketverzeichnis schreiben darf.
    • Dienst wieder aktiveren systemctl start <gps-dingens>.service
    • Anstöpseln
    • Gucken