Befehl in crontab wird nicht ausgeführt

[C.S. (Gast)]

Ich habe ein Debian-System, bei dem die serielle Schnittstelle nach dem 
Booten so definiert ist:

crw--w---- 1 root tty 251, 0 Jan 24 19:37 /dev/ttyS0

Ich bin Mitglied in der Gruppe tty und kann mit minicom auf die ttyS0 
nicht zugreifen, dazu brauche ich Lese- und Schreibrechte, also:

sudo chmod 0660 /dev/ttyS0

Geht prima:

crw-rw---- 1 root tty 251, 0 Jan 24 19:37 /dev/ttyS0

Nun möchte das natürlich dauerhaft machen, also die /etc/crontab 
geändert:

@reboot root sleep 10 && chmod 0660 /dev/ttyS0

Leider passiert nach dem Booten nix, es ist wieder der alte Mist:

crw--w---- 1 root tty 251, 0 Jan 24 19:45 /dev/ttyS0

Das gleiche Spielchen mit der /etc/rc.local, auch da geht es nicht.
Was tun?

[knollo (Gast)]

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

[knollo (Gast)]

Nachtrag: Deine Änderung gehört dann nach /etc/udev/rules.d

[C.S. (Gast)]

Habe jetzt eine Datei /etc/udev/rules.d/51-tty.rules

# /etc/udev/rules.d/51-tty.rules
# setzt Rechte für /dev/ttyS0 - ttyS9

SUBSYSTEM=="tty", KERNEL=="ttyS[0-9]*", GROUP="tty", MODE="0666"

hilft nur nix.

[blubb (Gast)]

Muss man nicht member von dialout sein um auf die Schnittstellen 
schrebien zudürfen?


http://wiki.gacq.com/index.php/Debian_default_system_groups_description

[C.S. (Gast)]

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

[Rolf M. (rmagnus)]

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:

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:

crw--w---- 1 root tty       4,  0 Jan 20 16:34 /dev/tty0

[Kaj G. (Firma: RUB) (bloody)]

Rolf M. schrieb:
> Welche Distribution ist das denn?

Da der TO was von
> /etc/rc.local
schreibt, tippe ich mal auf Debian.

[knollo (Gast)]

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

[C.S. (Gast)]

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.

[C.S. (Gast)]

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

@reboot  root  sleep 10 && udevadm trigger

Und es geht !!!

[c.m. (Gast)]

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

 @reboot /pfad/zum/script.sh

oder

 @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.:

 # crontab  -l
 SHELL=/bin/bash
 PATH=/home/kel/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

 10 */2 * * * /home/kel/bin/unison_backup.sh >/home/kel/messages  2>&1

[C.S. (Gast)]

c.m. schrieb:
> mach mal ein script daraus, und gibt immer den vollen pfad an, auch in
> der crontab.

Geht leider nicht.

[C.S. (Gast)]

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.