Bug#542125: ksysguardd: Blocks directories under /proc/acpi
tag 542125 +fixed-upstream upstream
thanks
Hi Frans
Thanks for your patch. It has been applied upstream and will at least land in
debian with the upload of kde 4.4.
I'm not sure this issues is important enough to warrant a stable update.
/Sune
On Tuesday 18 August 2009 01:19:26 Frans Pop wrote:
> Package: ksysguardd
> Version: 4:3.5.9.dfsg.1-6
> Severity: normal
> Tags: patch
>
> Today I needed to reload the kernel module thermal and was surprised to
> find that after the reload the directory /proc/acpi/thermal_zone/ empty
> was. Some extra testing showed the same happened for the modules fan
> and battery.
>
> Needless to say that having /proc directories for such common ACPI
> modules empty is not desirable.
>
> I also noticed that after module removal there still existed an empty
> directory /proc/acpi/thermal_zone. So my theory was that the old dir was
> "masksing" the newly created one.
> A look at the kernel source showed that the likely explanation for this
> was that some process was holding the directory open, thereby blocking
> the full release of the directory created by the "old" module.
>
> # lsof | grep /proc/acpi/ | awk '{print $1" "$5" "$9}'
> acpid REG /proc/acpi/event
> ksysguard DIR /proc/acpi/battery
> ksysguard DIR /proc/acpi/fan
> ksysguard DIR /proc/acpi/thermal_zone
>
> So, the culprit is ksysguardd.
>
> And the attached trivial patch fixes the issue.
>
> -- System Information:
> Debian Release: 5.0.2
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.31-rc6 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages ksysguardd depends on:
> ii libavahi-compat-libdnssd1 0.6.23-3lenny1 Avahi Apple Bonjour
> compatibility ii libc6 2.7-18 GNU C Library:
> Shared libraries ii libsensors4 1:3.0.2-1+b2 library to
> read temperature/voltag
>
> ksysguardd recommends no packages.
>
> ksysguardd suggests no packages.
>
> -- no debconf information
Reply to: