UPower-DEBUG messages with statement that BAT0 status did not changed

[Kay Sievers]

On Sat, Oct 15, 2011 at 18:25, Lars Schotte <gusto at guttok.net> wrote:
> i have here a minor problem that dbus spams in my messages file growing
> it to a few megabytes with the statement that the battery status did
> not change, what is not a surprise, isn't it?
>
> here are the messages i get:
>
> Oct 15 18:22:42 hana dbus-daemon[931]: (upowerd:1121):
> UPower-Linux-DEBUG: No updates on
> supply /org/freedesktop/UPower/devices/battery_BAT0 for 30 seconds;
> forcing update Oct 15 18:22:42 hana dbus-daemon[931]: (upowerd:1121):
> UPower-Linux-DEBUG: using min design voltage Oct 15 18:22:42 hana
> dbus-daemon[931]: (upowerd:1121): UPower-Linux-DEBUG: guessing battery
> state 'fully-charged': AC present: 1, AC online: 1 Oct 15 18:22:42 hana
> dbus-daemon[931]: (upowerd:1121): UPower-DEBUG: emitting changed
> on /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 Oct
> 15 18:22:42 hana dbus-daemon[931]: (upowerd:1121): UPower-DEBUG:
> emitting device-changed: /org/freedesktop/UPower/devices/battery_BAT0

It's upower logging debug information. Systemd connects the log
channels of tools now to syslog. These messages went to /dev/null on
older systems.

To fix this, glib's much too simple g_debug() needs to be fixed.
Alternatively tools can stop using glib's logging functions.

Unless a tool is explicitly set into debug mode, it should not write
anything to stderr by default. Even when connected to /dev/null, it
burns a lot of cycles with needlessly composing printf() strings to
write to /dev/null.

Kay