gkrellm and powering-off

[l.butler]

Has anyone noticed something similar to the following? Any suggestions to fix it?

If I run gkrellm--monitoring temp.s, cpu, hdd, eth0--then when I power-off my t22, the power-off sequence proceeds up to the final step, but ibm-acpi does not actually turn off the machine. That final step must be done manually.

If gkrellm is not run, then power-off is completed as it should.

[louieb]

For what its worth I'm running Ubuntu Feisty on a T30. I too use the gkrellm monitor and I have not had a problem with shutdown.

[l.butler]

What do you monitor with gkrellm?

Do you use the Gnome desktop with Ubuntu? I use KDE or fluxbox (the problem occurs in either case); I wonder if it is related in some way to the desktop/window manager.

I have been meaning to try Ubuntu. You response has persuaded me that I ought to try it.

[bradius]

Hmmm, that seems kind of strange. I used to run it the same way on my 600e without any problem. That was Suse 9.3 with fluxbox.

I'm really not sure about it, but I know I can't hibernate if anything is using my Windows' NTFS partition. Did you try it with different combinations of things being monitored as it could be related to one of them?

[louieb]

I use GNOME. GKrellm displays CPU, processes and users, temperatures for battery, cpu, hdd, and pci. disk and network usage, memory and swap usage, and have the plugin for led states (caps, num, scroll)

[lightweight]

Temp monitor may be calling ibm-acpi. Since GKrellM shuts down, I'd guess the problem is ibm-acpi. Any oddness in /var/log/messages?

[l.butler]

No, I haven't been able to find anything in /var/log/messages.

Originally, I thought that the problem might be related to either the temperature monitor (as you suggested), or the fact that gkrellm is designed for use with the Gnome desktop not KDE.

However, by stripping out all but the temp.s for gkrellm to monitor, I can now power-off successfully after running gkrellm for the whole session.

[lightweight]

However, by stripping out all but the temp.s for gkrellm to monitor, I can now power-off successfully after running gkrellm for the whole session.

Which monitor stops powering off from completing?

[l.butler]

I stopped all monitoring activities by gkrellm and then incrementally added new ones, beginning with temperatures, then cpu, procs, hda, eth0/ath0. With each addition, acpi_power_off was successfully called to power off the machine at shutdown. Then, I added "battery" to the list of things gkrellm monitors, and the old problem has reappeared. Since I am running the KDE desktop with its KLaptop utility that also monitors the battery's state, I suspect that the problem lies here.

This probably means that the problem is academic, since one probably does not need to use both gkrellm and klaptop to monitor the battery's state. Still, it is odd that there should be any conflict here.

Any edifying comments?

[lightweight]

KLaptop and GKrellM should both read /proc/acpi/battery (and /proc/acpi/ac_adapter when plugged in). ACPI and X all shut down cleanly when only running KLaptop or GKrellM?

I suggest looking for events whenever GKrellM polls battery state. You can do this by opening three terminals and executing one of the following in each:

Code: Select all

gkrellm -d 0x80

Code: Select all

tail -f /var/log/acpid

Code: Select all

tail -f /var/log/messages

Post output -- you're looking for events calling ACPI. Perhaps isolate if this is a problem when GKrellM is monitoring battery when plugged in or running on battery to see which ACPI status is borking it.

[l.butler]

Dumb question, lightweight: how do I turn on the log for the acpid daemon? Also, the daemon running is kacpid, but I don't suppose this changes things.

LB

[lightweight]

Hey, sorry for forgetting this. Not a dumb question. acpi should log to /var/log/acpid by default, but per the man page you can change the log location with the -l flag. Debian by default doesn't give regular users root's group and so /var/log/acpid is not readable, by the way. If you get a permission denied try invoking root.

If you have no log, I would first see how the command is invoked, kill it, then add the -l flag to some file to test. For example, on my Debian box:

Code: Select all

io@lightweight: ~ $ ps aux | grep acpi
root        25  0.0  0.0      0     0 ?        S<   Aug26   0:00 [kacpid]
root      3219  0.0  0.3   2080   968 ?        Ss   Aug26   0:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket 
io        3221  0.0  0.2   1752   520 pts/0    R+   01:51   0:00 grep acpi
io@lightweight: ~ $ sudo kill 3219
io@lightweight: ~ $ ps aux | grep acpi
root        25  0.0  0.0      0     0 ?        S<   Aug26   0:00 [kacpid]
io        3229  0.0  0.2   1752   520 pts/0    R+   01:51   0:00 grep acpi
io@lightweight: ~ $ sudo /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket  -l /var/log/acpi_now
io@lightweight: ~ $ ll !$ 
ll /var/log/acpi_now
-rw-r----- 1 root root 637 Aug 27 01:51 /var/log/acpi_now
io@lightweight: ~ $ sudo tail -f !$
sudo tail -f /var/log/acpi_now
[Mon Aug 27 01:52:02 2007] starting up
[Mon Aug 27 01:52:02 2007] 55 rules loaded
[Mon Aug 27 01:52:03 2007] client connected from 2915[0:0]
[Mon Aug 27 01:52:03 2007] 1 client rule loaded

I do not see anything in /etc/acpi that controls logging.

[l.butler]

There does not appear to be any connection between the power-off problem and the plugged-in status of the machine: monitoring the battery in both cases results in failure to complete the power off.

I installed the acpi daemon and logged the following output.

Code: Select all

lbutler@t22:/media/hda5/lbutler$ gkrellm -d 0x80
--- GKrellM 2.2.10 ---
hddtemp_daemon_read: can't connect to 127.0.0.1:7634.
libsensors support is not compiled in.
load_sensors_config: <sensor_config_version> <1>
load_sensors_config: <sensor_sysdep_private> <0>
load_sensors_config: <sensor_float_factor> <10000>
load_sensors_config: <gkrellm_float_factor> <1000>
load_sensors_config: <"BAT1"> <"IBM ACPI Battery 1" 10000 0 1 0>
load_sensors_config: <"BAT2"> <"IBM ACPI Battery 2" 10000 0 1 0>
load_sensors_config: <"CPU"> <"IBM ACPI CPU" 10000 0 1 0>
load_sensors_config: <"GPU"> <"IBM ACPI GPU" 10000 0 0 0>
load_sensors_config: <"HDD"> <"IBM ACPI HDD" 10000 0 0 0>
load_sensors_config: <"PCI"> <"IBM ACPI Mini PCI Module" 10000 0 0 0>
load_sensors_config: <"THM0"> <"thermal_zone/THM0" 10000 0 1 0>
load_sensors_config: <units_fahrenheit> <0>
load_sensors_config: <volt_display_mode> <0>
sensor_temp: BAT1 /proc/acpi/ibm/thermal t=45.00
sensor_temp: BAT2 /proc/acpi/ibm/thermal t=23.00
sensor_temp: CPU /proc/acpi/ibm/thermal t=48.00
sensor_temp: THM0 /proc/acpi/thermal_zone/THM0/temperature t=48.00

root@t22:~# cat /var/log/acpid_1.log
[Mon Aug 27 17:53:20 2007] starting up
[Mon Aug 27 17:53:20 2007] 1 rule loaded
[Mon Aug 27 18:00:49 2007] exiting
[Mon Aug 27 18:02:33 2007] starting up
[Mon Aug 27 18:02:33 2007] 1 rule loaded
[Mon Aug 27 18:04:03 2007] received event "battery BAT0 00000080 00000001"
[Mon Aug 27 18:04:03 2007] completed event "battery BAT0 00000080 00000001"
[Mon Aug 27 18:04:12 2007] received event "battery BAT0 00000080 00000001"
[Mon Aug 27 18:04:12 2007] completed event "battery BAT0 00000080 00000001"

root@t22:~# cat /var/log/messages | grep -i acpi | grep 'Aug 2[67]'
(extracts...)
Aug 27 18:02:33 t22 kernel: ACPI wakeup devices:
Aug 27 18:02:33 t22 kernel: ACPI: (supports S0 S1 S3 S4 S5)
Aug 27 18:02:33 t22 kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
Aug 27 18:02:33 t22 kernel: ACPI: Processor [CPU] (supports 8 throttling states)
Aug 27 18:02:33 t22 kernel: ACPI: Thermal Zone [THM0] (47 C)
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:03.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: AC Adapter [AC] (on-line)
Aug 27 18:02:33 t22 kernel: ACPI: Battery Slot [BAT0] (battery present)
Aug 27 18:02:33 t22 kernel: ACPI: Power Button (FF) [PWRF]
Aug 27 18:02:33 t22 kernel: ACPI: Lid Switch [LID]
Aug 27 18:02:33 t22 kernel: ACPI: Sleep Button (CM) [SLPB]
Aug 27 18:02:33 t22 kernel: ibm_acpi: IBM ThinkPad ACPI Extras v0.12a
Aug 27 18:02:33 t22 kernel: ibm_acpi: http://ibm-acpi.sf.net/
Aug 27 18:02:33 t22 kernel: ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11

[lightweight]

I do not see oddness, so I am still no help. Can you grep out the logs to data before shutdown attempt? (Can redirect gkrellm's 2&1 to a file.) In rereading the description I am hoping to see something call or fail on some wakeup for X.

[mdtaylor69]

I use GNOME. GKrellm displays CPU, processes and users, temperatures for battery, cpu, hdd, and pci. disk and network usage, memory and swap usage, and have the plugin for led states (caps, num, scroll)

So question for Lou is how to get the transparent charts? That is pretty slick.

[Harryc]

You can make the whole thing transparent if you want to, just install the 'invisible' theme in /home/youruser/.gkrellm2/themes

http://www.muhri.net/gkrellm/invisible.tar.gz



Restart gkrellm, then switch to the invisible theme in gkrellm config/themes.