search

puavo-org / puavo-os

Puavo OS is an disk image based operating system that is built from Debian GNU/Linux and is specifically designed for learning.
https://puavo.org
GNU General Public License v2.0
11 stars 7 forks source link

Somewhat excessive logging about udev rules in journalctl. #677

Open sarrchri opened 2 months ago

sarrchri commented 2 months ago

This happens at least on Bookworm. If my memory is right, I might've seen this on Bullseye too, but don't quote me on that :D Some udev rules seem to have executable permission bit set, while they shouldn't. So systemd-udevd tends to nag about this, sometimes it's quiet, sometimes it reports it multiple times in the course of a few minutes.

There's also some other output about those files, not necessarily related to the permission bits. These can add quite a bit of noise to the logs, so it might be something worth to look at.

Excerpt of the logs:

systemd-udevd[1314]: Configuration file /etc/udev/rules.d/40-libsane.rules is marked executable. Please remove executable permission bits. Proceeding anyway.
systemd-udevd[1314]: /etc/udev/rules.d/40-libsane.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
systemd-udevd[1314]: /etc/udev/rules.d/40-libsane.rules:26: The line takes no effect any more, dropping
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:58 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:110 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:175 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:184 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:246 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:282 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:284 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:286 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:383 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:404 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:407 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:410 The line takes no effect, ignoring.
systemd-udevd[1314]: /etc/udev/rules.d/51-android.rules:413 The line takes no effect, ignoring.
systemd-udevd[1314]: Configuration file /etc/udev/rules.d/S99-2000S1.rules is marked executable. Please remove executable permission bits. Proceeding anyway.
systemd-udevd[1314]: /etc/udev/rules.d/S99-2000S1.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
systemd-udevd[1314]: /etc/udev/rules.d/S99-2000S1.rules:26: The line takes no effect any more, dropping
juhaerk commented 2 months ago

Yes the Android lines are mostly fixed by this update: https://github.com/puavo-org/puavo-os/commit/65091240f3e83ddf5209d15b841fb2f24aacf75f

The rest (40-libsane.rules and S99-2000S1.rules) are created by hp-plugin downloader. I am guessing the old udevd did not warn about those and systemd-udevd does. I don't know if we should try to fix hp-plugin in any way, maybe leave that as it is?

Mazhoon commented 1 month ago

https://bugs.launchpad.net/hplip/+bug/1847477

Mazhoon commented 3 weeks ago

@sarrchri how's this with the latest test images? I think this should be a lot better now, but not running a real bookworm system myself so not totally sure

sarrchri commented 2 weeks ago

@Mazhoon Yes, with the latest test image from 2024-06-17 it does seem to be quiet when it comes to the lines listed previously. Haven't seen them anymore.

Though I did notice that there's quite a bit of colord-sane logging when plugging/unplugging USB-devices. Mainly multiple lines of io/hpmud/musb.c 2101: Invalid usb_open: Permission denied whenever a USB-device appears or disappears. Should that be made into another issue or do we want to keep this one as the main issue for too-verbose-logging?