Hallo,

ich habe ein sonderbares Problem mit meiner Udev Regel. Diese soll abhaengig vom Ladezustand meines Laptops ein Skript starten. Soweit so schoen:
[orschiro@thinkpad ~]$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[5852.805124] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ACPI0003:00/power_supply/AC (power_supply)
UDEV  [5852.815563] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ACPI0003:00/power_supply/AC (power_supply)
KERNEL[5852.904798] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [5852.905531] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[5852.905685] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [5852.906481] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[5858.631618] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ACPI0003:00/power_supply/AC (power_supply)
UDEV  [5858.653955] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ACPI0003:00/power_supply/AC (power_supply)
KERNEL[5858.733221] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [5858.734939] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
Meine Regel(n): 
#/etc/udev/rules.d/50-powersave-1.rules
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/home/orschiro/Scripts/powersaving battery"
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/home/orschiro/Scripts/powersaving AC"

#/etc/udev/rules.d/50-powersave-2.rules
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/home/orschiro/Scripts/powersaving battery"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/home/orschiro/Scripts/powersaving AC"
Das Skript wird nicht ausgefuehrt, funktioniert wenn ich es manuell starte aber einwandfrei.

In journalctl -b findet sich kein Hinweis:
Feb 16 09:41:15 thinkpad kernel: thinkpad_acpi: EC reports that Thermal Table has changed
Feb 16 09:41:18 thinkpad hdapsd[615]: parking
Feb 16 09:41:18 thinkpad kernel: thinkpad_acpi: EC reports that Thermal Table has changed
Feb 16 09:41:19 thinkpad hdapsd[615]: un-parking
Feb 16 09:41:21 thinkpad kernel: e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
Feb 16 09:41:21 thinkpad sudo[11379]: orschiro : TTY=pts/1 ; PWD=/home/orschiro ; USER=root ; COMMAND=/usr/bin/journalctl -b
Feb 16 09:41:21 thinkpad sudo[11379]: pam_unix(sudo:session): session opened for user root by orschiro(uid=0)
Feb 16 09:41:51 thinkpad sudo[11406]: orschiro : TTY=pts/5 ; PWD=/home/orschiro ; USER=root ; COMMAND=/usr/bin/udevadm control --reload
Feb 16 09:41:51 thinkpad sudo[11406]: pam_unix(sudo:session): session opened for user root by orschiro(uid=0)
Feb 16 09:41:51 thinkpad sudo[11406]: pam_unix(sudo:session): session closed for user root
Feb 16 09:41:54 thinkpad sudo[11379]: pam_unix(sudo:session): session closed for user root
Feb 16 09:41:55 thinkpad kernel: thinkpad_acpi: EC reports that Thermal Table has changed
Feb 16 09:41:58 thinkpad kernel: thinkpad_acpi: EC reports that Thermal Table has changed
Feb 16 09:41:59 thinkpad sudo[11547]: orschiro : TTY=pts/1 ; PWD=/home/orschiro ; USER=root ; COMMAND=/usr/bin/journalctl -b
Feb 16 09:41:59 thinkpad sudo[11547]: pam_unix(sudo:session): session opened for user root by orschiro(uid=0)
Feb 16 09:42:00 thinkpad kernel: e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
Feb 16 09:42:09 thinkpad sudo[11547]: pam_unix(sudo:session): session closed for user root
Feb 16 09:42:10 thinkpad sudo[11611]: orschiro : TTY=pts/1 ; PWD=/home/orschiro ; USER=root ; COMMAND=/usr/bin/journalctl -b
Feb 16 09:42:10 thinkpad sudo[11611]: pam_unix(sudo:session): session opened for user root by orschiro(uid=0)
Die Regel wird vom System aber definitv erkannt. Habe testweise mal einen Fehler eingebaut und siehe da, sie erscheint im Log:
Feb 16 09:41:15 thinkpad systemd-udevd[136]: invalid ACTION operation
Feb 16 09:41:15 thinkpad systemd-udevd[136]: invalid rule '/etc/udev/rules.d/50-powersave.rules:1'
Feb 16 09:41:15 thinkpad systemd-udevd[136]: invalid ACTION operation
Feb 16 09:41:15 thinkpad systemd-udevd[136]: invalid rule '/etc/udev/rules.d/50-powersave.rules:2'
Hat jemand von euch eine Idee, warum die Regel mein Skript nicht ausfuehrt?

Folgende Regel fuehrt den echo Command uebrigens auch nicht aus:
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/bin/echo test >> /home/orschiro/test"
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/bin/echo test2 >> /home/orschiro/test"
5 Tage später
So ein kleines Update. Mir ist nach wie vor unerklaerlich, wo das genau Problem besteht. Allerdings funktioniert es nun wieder in soweit, dass mein Skript nun waehrend der Laufzeit wieder ausgefuehrt wird.

Meine Udev Regel:
[orschiro@thinkpad ~]$ cat /etc/udev/rules.d/50-powersave.rules 
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/home/orschiro/Scripts/powersaving battery"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/home/orschiro/Scripts/powersaving AC"
Mein modifiziertes Skript, das nun nicht mehr xbacklight verwendet:
[orschiro@thinkpad ~]$ cat Scripts/powersaving 
#!/bin/sh

case $1 in
    battery)
		echo "Running powersaving on AC"
		
		# screen power saving"
		echo 200000 > /sys/class/backlight/intel_backlight/brightness
    ;;
    AC)
		echo "Running powersaving on battery"
	    
		# screen power saving
		echo 4270725 > /sys/class/backlight/intel_backlight/brightness
    ;;
esac
Kann mir aber jemand erklaeren, warum die Udev Regel nicht beim Boot ausgefuehrt wird? Sprich, wenn meine Bildschirmhelligkeit komplett runterreguliert ist und ich den Laptop mit angeschlossenem Kabel neustarte, verbleibt die Helligkeit runtergeregelt. Stoepsle ich das Kabel daraufhin raus und wieder rein, wird die Udev Regel korrekt angewendet.
Nun ist mir das Problem klar geworden!

Die Udev Regel schlug beim Boot aus zwei Gruenden fehl:

1. /home/orschiro/Scripts/powersaving existiert waehrend der Ausfuehrung der Udev Regel nicht, da /home zu dem Zeitpunkt noch nicht gemounted ist. Loesung hierfuer ist das Skript in /usr/local/bin zu geben.

2. Nun wird powersaving ausgefuehrt, greift aber auf /sys/class/backlight zurueck, das zum Zeitpunkt des Ausfuehrens der Udev Regel aber auch noch nicht existiert.

Frage: Gibt es eine elegante Moeglichkeit, um eine Udev Regel beim Start etwas warten zu lassen?
Du könntest natürlich in dem Skript ein sleep einbauen. Oder hängt dadurch dann der komplette Bootprozess?
Wie wärs, das mit systemd zu lösen? Dann quasi ein powersave.service anlegen, welches halt beim Booten 1x das Skript ausführt. Da müsstest halt das Skript ändern, damit es erkennt, ob du online oder offline bist.

Kenn mich mit udev kaum aus, daher kann es sein, dass das egal ist. Aber bei powerdown ist es so implementiert 
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/usr/bin/powerdown"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/usr/bin/powerup"
und als ich das noch benutzt hatte, da ging das mit der Helligkeit.
orschiro schrieb 2. Nun wird powersaving ausgefuehrt, greift aber auf /sys/class/backlight zurueck, das zum Zeitpunkt des Ausfuehrens der Udev Regel aber auch noch nicht existiert.
Dann formuliere doch eine udev-Regel für eben dieses Device. Dabei kannst du das Attribut direkt in der Regel setzen ohne ein Script aufrufen zu müssen.
https://bbs.archlinux.org/viewtopic.php?pid=1193741#p1193741
Army schriebDu könntest natürlich in dem Skript ein sleep einbauen. Oder hängt dadurch dann der komplette Bootprozess?
Habe das nun in der Tat so geloest. Siehe unten.
Wie wärs, das mit systemd zu lösen? Dann quasi ein powersave.service anlegen, welches halt beim Booten 1x das Skript ausführt. Da müsstest halt das Skript ändern, damit es erkennt, ob du online oder offline bist.
Da halte ich den sleep-Ansatz fuer simpler.
Kenn mich mit udev kaum aus, daher kann es sein, dass das egal ist. Aber bei powerdown ist es so implementiert 
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/usr/bin/powerdown"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/usr/bin/powerup"
und als ich das noch benutzt hatte, da ging das mit der Helligkeit.
Ich denke, das haengt nicht mit der Udev Regel zusammen, sondern ist abhaengig von der Hardware.
hydro schrieb
orschiro schrieb 2. Nun wird powersaving ausgefuehrt, greift aber auf /sys/class/backlight zurueck, das zum Zeitpunkt des Ausfuehrens der Udev Regel aber auch noch nicht existiert.
Dann formuliere doch eine udev-Regel für eben dieses Device. Dabei kannst du das Attribut direkt in der Regel setzen ohne ein Script aufrufen zu müssen.
https://bbs.archlinux.org/viewtopic.php?pid=1193741#p1193741
Damit kann ich aber nicht die Helligkeit in Abhaengigkeit vom Batteriestatus setzen. Hierfuer brauche ich die folgende Regel in Kombination mit meinem powersaving Skript:
[orschiro@thinkpad ~]$ cat /etc/udev/rules.d/50-powersave.rules 
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/local/bin/powersaving battery"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/local/bin/powersaving AC"
[orschiro@thinkpad ~]$ cat /usr/local/bin/powersaving 
#!/bin/sh

case $1 in
    battery)
		echo "Running powersaving on AC in 3 seconds"
		sleep 3
		# screen power saving"
		echo 200000 > /sys/class/backlight/intel_backlight/brightness
    ;;
    AC)
		echo "Running powersaving on battery in 3 seconds"
	    	sleep 3
		# screen power saving
		echo 4270725 > /sys/class/backlight/intel_backlight/brightness
    ;;
esac
orschiro schrieb Damit kann ich aber nicht die Helligkeit in Abhaengigkeit vom Batteriestatus setzen.
Der Status lässt sich nicht ermitteln?
Der Status laesst sich per Udev Regel durchaus ermitteln. Genau das macht ja meine Regel. Ich muesste also quasi meine mit der von dir verlinkten Regel kombinieren. Hat jemand eine Idee, wie das aussehen koennte?

Statusermittlung:
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/local/bin/powersaving battery"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/local/bin/powersaving AC"
Helligkeit aendern:
ACTION=="add", KERNEL=="acpi_video0", SUBSYSTEM=="backlight", SUBSYSTEMS=="pci", DRIVERS=="i915", ATTR{brightness}="2"
Es muesste also lauten: Wenn von SUBSYSTEM=="power_supply" die ENV{POWER_SUPPLY_ONLINE}=="0", dann von SUBSYSTEM=="backlight" das ATTR{brightness}="2"
So scheint es zu funktionieren 
ACTION=="add", KERNEL=="acpi_video0", SUBSYSTEM=="backlight", SUBSYSTEMS=="pci", DRIVERS=="i915", PROGRAM="/usr/local/bin/udevbacklight.sh", ATTR{brightness}="%c{1}"
wobei %c{1} die stdout-Ausgabe von /usr/local/bin/udevbacklight.sh ist 
#!/bin/bash
case $(cat /sys/class/power_supply/AC0/online 2>/dev/null) in
 0) echo 3;;
 1) echo 9;;
 *) echo 6;;
esac
Danke hydro!

Hatte bisher noch keine Gelegenheit, deinen Ansatz auszuprobieren. Allerdings gefaellt mir das ganz gut.

Alternativ habe ich mit einem 3 Sekunden sleep in meinem Backlight Script experimentiert. Das reicht, um beim Boot auf die Einbindung von /sys/class/backlight zu warten und stoert waehrend der Laufzeit auch nicht sondernlich, 3 Sekunden auf einen Wechsel von geringer zu maximaler Helligkeit zu warten.
Wollte nun deine Methode ausprobieren. Leider funktioniert sie nicht. Udev beklagt fehlende write permissions:
rules contain 196608 bytes tokens (16384 * 12 bytes), 29071 bytes strings
16404 strings (148211 bytes), 13925 de-duplicated (121620 bytes), 2480 trie nodes used
PROGRAM '/usr/local/bin/udevbacklight.sh' /etc/udev/rules.d/50-powersave.rules:1
starting '/usr/local/bin/udevbacklight.sh'
'/usr/local/bin/udevbacklight.sh' [4742] exit with return code 0
ATTR '/sys/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/brightness' writing '12' /etc/udev/rules.d/50-powersave.rules:1
error opening ATTR{/sys/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/brightness} for writing: Permission denied
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
SUBSYSTEM=backlight
USEC_INITIALIZED=1014635160
unload module index
Manuell kann ich jedoch schreiben:
[root@thinkpad acpi_video0]# echo 12 > /sys/devices/pci0000\:00/0000\:00\:02.0/backlight/acpi_video0/brightness
Habe deine Regel an mein System angepasst: 
[orschiro@thinkpad ~]$ cat /etc/udev/rules.d/50-powersave.rules 
ACTION=="add", DEVPATH=="/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0", SUBSYSTEM=="backlight", SUBSYSTEMS=="pci", DRIVERS=="i915", PROGRAM="/usr/local/bin/udevbacklight.sh", ATTR{brightness}="%c{1}"
Eine Idee, warum Udev nicht mit Schreibrechten schreiben kann?

Zum Schluss noch der Output von udevadm:
[orschiro@thinkpad acpi_video0]$ udevadm info -a -p /sys/class/backlight/acpi_video0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0':
    KERNEL=="acpi_video0"
    SUBSYSTEM=="backlight"
    DRIVER==""
    ATTR{type}=="firmware"
    ATTR{brightness}=="12"
    ATTR{bl_power}=="0"
    ATTR{max_brightness}=="15"
    ATTR{actual_brightness}=="12"

  looking at parent device '/devices/pci0000:00/0000:00:02.0':
    KERNELS=="0000:00:02.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="i915"
    ATTRS{irq}=="48"
    ATTRS{subsystem_vendor}=="0x17aa"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x030000"
    ATTRS{consistent_dma_mask_bits}=="36"
    ATTRS{dma_mask_bits}=="36"
    ATTRS{local_cpus}=="00000000,00000003"
    ATTRS{device}=="0x2a42"
    ATTRS{msi_bus}==""
    ATTRS{local_cpulist}=="0-1"
    ATTRS{vendor}=="0x8086"
    ATTRS{subsystem_device}=="0x20e4"
    ATTRS{boot_vga}=="1"
    ATTRS{numa_node}=="-1"
    ATTRS{d3cold_allowed}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""
Wenn ich OWNER="root" zur Regel hinzufuege, dann bekomme ich zumindest nicht mehr den Permission Denied error. Dennoch ist Udev nicht in der Lage das ATTR{brightness} in die Datei nach /sys/class/backlight zu schreiben. Im Gentoo Forum habe ich jedoch gelesen, dass man dies auch nicht tun soll und stattdessen die Udev Regel nutzen, um ein Skript aufzurufen, das seinerseits einen Wert nach /sys/class/ schreibt.

Heisst fuer mich, ich bleibe bei meiner Regel und meinem Skript von oben.
Das klingt jetzt ein wenig so, als sollte man immer den Umweg über ein Script nehmen. Ohne Script kommen wir in diesem Fall zwar ohnehin nicht aus (du könntest auch in udevbacklight.sh direkt nach /sys/class/ schreiben), aber wie dein Bugreport nahelegt, muss schon etwas im argen sein, wenn udev bei dir keine Attribute setzen kann (wie es auch in einigen Regeln unter /usr/lib/udev/rules.d/ geschieht). 
[root@linux ~]# ls -l /sys/class/backlight/acpi_video0/brightness 
-rw-r--r-- 1 root root 4096  2. Mär 10:18 /sys/class/backlight/acpi_video0/brightness
[root@linux ~]# cat /sys/class/backlight/acpi_video0/brightness 
2
[root@linux ~]# cat /etc/udev/rules.d/50-powersave.rules
ACTION=="add", KERNEL=="acpi_video0", SUBSYSTEM=="backlight", SUBSYSTEMS=="pci", DRIVERS=="i915", ATTR{brightness}="4"
[root@linux ~]# udevadm test /sys/class/backlight/acpi_video0
...
rules contain 196608 bytes tokens (16384 * 12 bytes), 30397 bytes strings
19730 strings (167693 bytes), 16940 de-duplicated (140087 bytes), 2791 trie nodes used
ATTR '/sys/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/brightness' writing '4' /etc/udev/rules.d/50-powersave.rules:1
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
SUBSYSTEM=backlight
UDEV_LOG=6
USEC_INITIALIZED=1985727717
unload module index
[root@linux ~]# cat /sys/class/backlight/acpi_video0/brightness 
4
4 Tage später
Das mit den Attributen hat mich auch etwas verwundert. Bisher habe ich allerdings keine negativen Erscheinungen auf meinem System. Werde das aber auf alle Faelle mal beobachten.

Oder hast du noch eine Idee, woran das liegen koennte?