Guten Abend !
Ich kann Dir die exakte Syntax jetzt nicht sagen, aber genau dafür mußt
Du eine udev-Regel erstellen. Schau mal unter /lib/udev/rules.d nach,
bei mir (Arch) werden die ser. Schnittstellen in der Default-Rule
konfiguriert.
MfG Knollo
blubb schrieb:> Muss man nicht member von dialout sein um auf die Schnittstellen> schrebien zudürfen?
Hier ist es die Gruppe tty, wie Du an der Zeile aus dem Listing siehst
1
crw--w---- 1 root tty 251, 0 Jan 24 19:37 /dev/ttyS0
C.S. schrieb:> blubb schrieb:>> Muss man nicht member von dialout sein um auf die Schnittstellen>> schrebien zudürfen?>> Hier ist es die Gruppe tty, wie Du an der Zeile aus dem Listing> siehst> crw--w---- 1 root tty 251, 0 Jan 24 19:37 /dev/ttyS0
Welche Distribution ist das denn? Ich kenne es auch nur so, dass ttyS*,
ttyUSB* u.s.w. zur Gruppe dialout gehören und dass die Gruppe auch
sowohl Lese- als auch Schreibzugriff hat. Irgendwas scheint da bei dir
verkorkst zu sein.
Auch die minor-inode-Nummer sieht merkwürdig aus.
Bei mir sieht es standardmäßig so aus:
1
crw-rw---- 1 root dialout 4, 64 Jan 20 16:34 /dev/ttyS0
Deine Ausgabe sieht eher aus wie das, was eigentlich zu /dev/tty0
gehört:
Hallo !
Meine Erfahrung lehrt, das es nicht auf Anhieb gelingt, also etwas
Geduld!
Eventl. liegt's an der Reienfolge de Abarbeitung. Benenne
/etc/udev/rules.d/51-tty.rules in /etc/udev/rules.d/90-tty.rules um !
Wenn Du MODE="0666" schreibst, darf jeder (was ja eventl. gewollt ist)
auf die Schnittstelle zugreifen. Die Quick & Dirty Lösung ist die
direkte Änderung in /lib/udev. Das kann dann allerdings nach einem
Update wieder weg sein. Nach den Änderungen den udev neu starten, damit
dieser seine Konfiguration neu einliest! Ach ja, was sagt denn das
Syslog?
MfG Knollo
Erst mal vielen Dank für die Tips.
Leider hat auch die Umnummerierung der udev-Rule nichts gebracht, nach
einem Reboot sind die Rechte der Gruppe nur auf W gesetzt. Ich habe habe
aber herausgefunden, dass der Neustart des udev-Systems mit 'sudo
udevadm trigger' doch noch zu einer korrekten Einstellung auf RW führt.
Aber dann kann ich auch hergehen und das mit chmod machen. Komisch finde
ich nach wie vor, dass chmod auch mit Wartezeit weder in der crontab
noch in der rc.local zum gewünschten Ergebnis führt, bei manueller
Eingabe im Terminal dagegen schon.
Zur Frage des "verkorksten" Systems: das ist das Debian-Derivat armbian,
welches auf einem Orangepi-One läuft. Ich habe hier etliche Rechner
rumliegen, alle auf Debian-Basis, da ist das mal so und mal so. Die
Gruppe der /dev/ttyS0 kann tty oder auch dialout sein, mal sind die
Rechte auf W und manchmal auf RW gesetzt. Meine Arbeitsrechner mit
Ubuntu 16.04 LTS machen das mit RW und dialout immer richtig, ein Zesty
auf einem Proberechner macht nur ein W, ein Debian Jessie macht ein RW,
ein Debian Stretch macht ein W, bei 4 Raspberries sind 3 so und 1
anders. Alles SEHR merkwürdig.
Beim lesen meines eigenen Beitrages kam mir eine Idee, die ist zwar
"durch die Schulter ins Knie", funktioniert aber:
Die udev-Regel funktioniert ja prinzipiell, aber nicht auf von alleine.
Das kann am systemd beim Start liegen, wo manche Dinge quasi parallel
ablaufen. Wenn die udev-Regel angewendet wird, ist die Schnittstelle
möglicherweise noch nicht aktiv. Also habe ich in die crontab eine Regel
rein, die nach einem reboot 10 Sekunden wartet und dann das udev-System
neu startet
C.S. schrieb:> Komisch finde> ich nach wie vor, dass chmod auch mit Wartezeit weder in der crontab> noch in der rc.local zum gewünschten Ergebnis führt, bei manueller> Eingabe im Terminal dagegen schon.
mach mal ein script daraus, und gibt immer den vollen pfad an, auch in
der crontab.
#!/bin/bash nicht vergessen
1
@reboot /pfad/zum/script.sh
oder
1
@reboot /bin/bash /pfad/zum/script.sh
cron hat manchmal probleme mit der ${PATH} variblan - da steht dann
vielleicht nur /bin und /sbin drin.
ich denke mal, dass dein cron modern genug ist, dass du in der crontab
auch PATH exportieren kannst.
so z.b.:
C.S. schrieb:>> mach mal ein script daraus, und gibt immer den vollen pfad an, auch in>> der crontab.>> Geht leider nicht.
Im 2. Anlauf ging es dann doch, da kann ich mir sogar den Umweg mit den
Rules sparen.