| Summary: | Journald can cause an endless loop | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Bartlomiej Gluch <bartlomiej.gluch.ext> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED NOTOURBUG | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | ARM | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Bartlomiej Gluch
2014-04-01 07:43:09 UTC
(In reply to comment #0) > dev_dbg creates an syslog entry - which triggers journald to read uevent > file for this device, which than again dev_dbg() is called causing journald > to read uevent file - so there is an endless loop (technically, kernel will > kill journald after some time) This sounds like a bug in the kernel. Most important, the conceptually broken idea of the power_supply class to transport *measurement data*, *user access* or other unrelated things over uevents should really be fixed, it cannot fly. Uevents were never made for such a use case, uevents are very expensive events for global device state changes regarding the device and its *integration* into system management; there must never be any uevents generated for normal expected device operations like device access or charge level changes. Please try to get the specific kernel driver fixed, or even the power_supply class itself fixed. What userspace is doing here sounds totally fine and nothing should need to work around such kernel brokeness. This kernel behaviour makes no sense for userspace. I observe same infinite loop. systemd-journald read following: p=7,5120,282337378,-;power_supply AC: prop ONLINE=1 SUBSYSTEM=power_supply DEVICE=+power_supply:AC and then read '/sys/class/power_supply/AC/uevent' again which cause above message again => infinite loop (100% CPU usage by systemd-journald). If this kernel bug do we need to send bug report/patch to kernel ? For now I have disabled 'CONFIG_POWER_SUPPLY_DEBUG'. For me this 'fix' is ok (I don't need this debug). Here is backtrace: /dev/kmsg buffer overrun, some messages lost. Breakpoint 1, device_read_uevent_file (device=0x5555555caf20) at src/libsystemd/sd-device/sd-device.c:482 482 in src/libsystemd/sd-device/sd-device.c (gdb) bt #0 device_read_uevent_file (device=0x5555555caf20) at src/libsystemd/sd-device/sd-device.c:482 #1 0x0000555555587368 in sd_device_get_devname (device=0x5555555caf20, devname=0x7fffffffb8d0) at src/libsystemd/sd-device/sd-device.c:933 #2 0x0000555555581b14 in udev_device_get_devnode (udev_device=0x5555555cacb0) at src/libudev/libudev-device.c:677 #3 0x000055555555be2d in dev_kmsg_record (s=0x7fffffffe450, p=0x7fffffffc2c3 "power_supply AC: prop ONLINE=1", l=0) at src/journal/journald-kmsg.c:228 #4 0x000055555555c834 in server_read_dev_kmsg (s=0x7fffffffe450) at src/journal/journald-kmsg.c:348 #5 0x000055555555cb13 in dispatch_dev_kmsg (es=0x5555555c96b0, fd=7, revents=1, userdata=0x7fffffffe450) at src/journal/journald-kmsg.c:390 #6 0x000055555558d0c1 in source_dispatch (s=0x5555555c96b0) at src/libsystemd/sd-event/sd-event.c:2114 #7 0x000055555558e4f8 in sd_event_dispatch (e=0x5555555c91e0) at src/libsystemd/sd-event/sd-event.c:2471 #8 0x000055555558e670 in sd_event_run (e=0x5555555c91e0, timeout=18446744073709551615) at src/libsystemd/sd-event/sd-event.c:2499 #9 0x000055555555ae0d in main (argc=1, argv=0x7fffffffe768) at src/journal/journald.c:106 (gdb) frame 3 #3 0x000055555555be2d in dev_kmsg_record (s=0x7fffffffe450, p=0x7fffffffc2c3 "power_supply AC: prop ONLINE=1", l=0) at src/journal/journald-kmsg.c:228 228 src/journal/journald-kmsg.c: No such file or directory. (gdb) p kernel_device $1 = 0x5555555ca5ef "+power_supply:AC" |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.