Re: [systemd-devel] Order between systemd-networkd and udev
On Mon, Nov 30, 2020, 23:25 Zheng, Fam wrote: > Hi, > > Currently in systemd-networkd.service we have > > After=... systemd-udevd.service ... > > I know the point of it has been for tuntap as pointed out by comments > above, but I do wonder what ensures the ordering of NIC drivers (as > loaded by udevd) against networkd? > Networkd shouldn't ever *need* such synchronization – each interface gets configured whenever it appears, whether it's earlier or later. Basically all interfaces are hotplug interfaces. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev ATTR can have double dots and help writing a rule
So this is the eventual rule I ended up writing after having a lot of
trouble writing a udev rule:
`ACTION=="add", SUBSYSTEM=="ata_port", KERNEL=="ata[0-9]",
TEST=="../../power/control" ATTR{../../power/control}="auto"`
Here is the rule working:
```
Dec 01 01:33:16 arch systemd-udevd[267]: ata1:
/etc/udev/rules.d/user-powertop-tunables.rules:5 ATTR
'/sys/devices/pci:00/:00:13.0/ata1/ata_port/ata1/../../power/control'
writing 'auto'
Dec 01 01:33:16 arch systemd-udevd[258]: ata2:
/etc/udev/rules.d/user-powertop-tunables.rules:5 ATTR
'/sys/devices/pci:00/:00:13.0/ata2/ata_port/ata2/../../power/control'
writing 'auto'
```
Is this a good udev rule or even valid or is using `..` something that
shouldn't be possible?
Before settling on the above rule I was using:
`ACTION=="add", DEVPATH=="/devices/pci:00/:00:13.0",
ATTR{ata1/power/control}="auto"`
Here was that rule working:
`Nov 30 18:26:02 arch systemd-udevd[264]: ata1:
/etc/udev/rules.d/user-powertop-tunables.rules:4 ATTR
'/sys/devices/pci:00/:00:13.0/ata1/ata_port/ata1/power/control'
writing 'auto'`
Obviously I'd need to add the `TEST` and then I run into the problem
that I have to write a rule for every single number.
So can anyone help me figure this all out?
Some udevadm info commands:
```
udevadm info -q all --path=/sys/bus/pci/devices/:00:13.0/ata1/ata_port/ata1
P: /devices/pci:00/:00:13.0/ata1/ata_port/ata1
L: 0
E: DEVPATH=/devices/pci:00/:00:13.0/ata1/ata_port/ata1
E: SUBSYSTEM=ata_port
```
```
$ udevadm info -a --path=/sys/bus/pci/devices/:00:13.0/ata1/ata_port/ata1
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/pci:00/:00:13.0/ata1/ata_port/ata1':
KERNEL=="ata1"
SUBSYSTEM=="ata_port"
DRIVER==""
ATTR{idle_irq}=="0"
ATTR{nr_pmp_links}=="0"
ATTR{port_no}=="1"
ATTR{power/async}=="disabled"
ATTR{power/control}=="auto"
ATTR{power/runtime_active_kids}=="0"
ATTR{power/runtime_active_time}=="0"
ATTR{power/runtime_enabled}=="disabled"
ATTR{power/runtime_status}=="unsupported"
ATTR{power/runtime_suspended_time}=="0"
ATTR{power/runtime_usage}=="0"
looking at parent device '/devices/pci:00/:00:13.0/ata1':
KERNELS=="ata1"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{power/async}=="enabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="1"
ATTRS{power/runtime_active_time}=="1713418"
ATTRS{power/runtime_enabled}=="enabled"
ATTRS{power/runtime_status}=="active"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="0"
looking at parent device '/devices/pci:00/:00:13.0':
KERNELS==":00:13.0"
SUBSYSTEMS=="pci"
DRIVERS=="ahci"
ATTRS{ari_enabled}=="0"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x010601"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x22a3"
ATTRS{devspec}==""
ATTRS{dma_mask_bits}=="64"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="117"
ATTRS{local_cpulist}=="0-3"
ATTRS{local_cpus}=="f"
ATTRS{msi_bus}=="1"
ATTRS{msi_irqs/117}=="msi"
ATTRS{numa_node}=="-1"
ATTRS{power/async}=="enabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="1"
ATTRS{power/runtime_active_time}=="1716855"
ATTRS{power/runtime_enabled}=="enabled"
ATTRS{power/runtime_status}=="active"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="1"
ATTRS{power/wakeup}=="disabled"
ATTRS{power/wakeup_abort_count}==""
ATTRS{power/wakeup_active}==""
ATTRS{power/wakeup_active_count}==""
ATTRS{power/wakeup_count}==""
ATTRS{power/wakeup_expire_count}==""
ATTRS{power/wakeup_last_time_ms}==""
ATTRS{power/wakeup_max_time_ms}==""
ATTRS{power/wakeup_prevent_sleep_time_ms}==""
ATTRS{power/wakeup_total_time_ms}==""
ATTRS{revision}=="0x35"
ATTRS{subsystem_device}=="0x074d"
ATTRS{subsystem_vendor}=="0x1028"
ATTRS{vendor}=="0x8086"
looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{power/async}=="enabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="7"
ATTRS{power/runtime_active_time}=="0"
ATTRS{power/runtime_enabled}=="disabled"
ATTRS{power/runtime_status}=="unsupported"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="0"
```
```
$ udevadm info -q all --path=/sys/bus/pci/devices/:00:13.0/ata1
P: /devices/pci:00/:00:13.0/ata1
```
```
$ udevadm info -a --path=/sys/bus/pci/devices/:00:13.0/ata1
Udeva
[systemd-devel] Antw: [EXT] journalctl -f after restart of journald
Hi! I forgot: What I'd expect at least to see in the "old" journalctl -f is this log message: -- Logs begin at Wed 2020-11-25 11:27:53 CET. -- Nov 30 12:03:27 h19 systemd-journald[957]: Received SIGTERM from PID 1 (systemd). Regards, Ulrich >>> "Ulrich Windl" schrieb am 30.11.2020 um 12:08 in Nachricht <5fc4d2b902a10003d...@gwsmtp.uni-regensburg.de>: > Hi! > > I just made an "interesting" observation: When running "journalctl ‑f" there > is no message when journald restarts, meaning you'll have to restart > "journalctl ‑f", too to see any messages after journald has been restarted. > > Is this the way it is designed? > > (systemd‑234‑24.64 of SLES15 SP2) > > Regards, > Ulrich > > > > ___ > systemd‑devel mailing list > systemd‑de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journalctl -f after restart of journald
Hi! I just made an "interesting" observation: When running "journalctl -f" there is no message when journald restarts, meaning you'll have to restart "journalctl -f", too to see any messages after journald has been restarted. Is this the way it is designed? (systemd-234-24.64 of SLES15 SP2) Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
