provide a way to disable drive polling

Turns out uncommenting that storage.automount_enabled_hint line (to make it
false) doesn't solve the problem.

In hoary, I needed to add two lines: one for storage_media_check_enabled and one
for storage_automount_enabled_hint, setting both to false in /etc/hal/hald.conf.
That worked. Since the commented-out line in breezy references
storage.automount_enabled_hint (note the . instead of the first underscore), I
also tried adding a line for storage.media_check_enabled, but setting both of
those to false doesn't cure the problem in breezy. I also tried it with the
underscores (like in hoary) but that didn't work either.

Sorry for the bugspam -- wanted to add that I also tried putting in a
/etc/hal/hald.conf (the same one I used in hoary) even though breezy doesn't
have that file by default, but that doesn't help either.

This is still a problem on Dapper Flight 3. I have it on my desktop, where I can't hear the disk over the fan noise, but I can see the disk light flicker roughly once a second until I kill hald.

Hm, I just eyeballed the code to find out why media_check_enabled is true for your hard drive, but I could not find an obvious flaw.

Can you please (temporarily) remove all custom configurations, set up an up to date dapper, do

  lshal > lshal.txt

and attach lshal.txt here?

Also, it could help me to see a full hald debug output from your system. This is described on the second half of http://wiki.ubuntu.com/DebuggingRemovableDevices.

Thank you!

Here's lshal.txt from the laptop immediately following an install of Dapper flight 6.

Here's a hal.log output (from the beginning to where it stops spewing). No removable devices are involved in this problem, just the fixed internal ide disk, so I ignored that part of the instructions.

In case it wasn't clear from the earlier comment, I see this problem on my desktop machine too, not just the Vaio laptop, but on the desktop machine the only clue is the disk light flashing every second or so (the processor fan and disk are too loud to hear whether the disk is beeping or making any other sound like that). So I don't think this is specific to any unusual hardware on this machine. If it would help to have lshal or hald output from the desktop machine for comparison, let me know.

I'm still puzzled. Your lshal shows that the media check is disabled for your hard drive. Just to be 100% sure, can you please copy&paste this beast into a terminal shell:

sudo sh -c "for i in `pidof /usr/lib/hal/hald-addon-storage`; do tr '\000' '\n' < /proc/$i/environ; echo '==='; done" > storage-probes.txt

and attach storage-probes.txt here?

Also, can you confirm that the hd access stops after

  sudo /etc/dbus-1/event.d/20hal stop

(do the same with 'start' instead of 'stop' to start hal again).

Thank you!

btw, above command is just one line; please make sure that there are no line breaks. thanks!

Here's storage-probes.txt.

Yes, the access does stop after the 20hal stop command.

Thanks; storage-probes.txt confirmed that hal really just polls the USB drive with the addon-storage. So it must be something else...

Can you please do

  sudo strace -f -o hald.trace -p `pidof hald`

let that run for a while (maybe a minute), then press Control-C and attach hald.trace here?

Here's the trace from just over a minute.

Thanks for the strace. So the main hald process does not do any disk access during that time. So let's do a more fine-grained testing: Let's kill the addons one by one and check which one is the culprit:

  ps axo pid,cmd |grep hald-addon

This will show you a list of running hald helpers with their process ID number in front of it. Please use 'sudo kill <process ID>' to kill one after another and check in between whether the repeated disk access still happens. If it stops after killing a particular addon, please tell me its name. If it didn't stop, and the only processes left in

  ps aux|grep hal

are 'hald' and 'hald-runner', then the culprit must be some other program (probably some that listens to hal via dbus) and we have to dig deeper.

Thank you!

I started with four processes: -acpi, -keyboard, and two -storage processes.

Killing the second -storage process didn't stop the access, but when I killed the first one as well, the beeping stopped.

Ah, great, so we surrounded the culprit at least. :)

So let's do the strace dance for these two helpers. Please restart hal (just rebooting is easiest, or do sudo
/etc/dbus-1/event.d/20hal restart), then find out the process IDs of the storage addons:

  ps axo pid,cmd |grep hald-addon-storage

Then, for each pid, do

  sudo strace -f -o PID.trace -p PID

(replace 'PID' by the current pid you are examining) and let it run for a minute, then press Ctrl+C.

Then, please find out which of the two processes was responsible for the disk access (by killing one and checking whether or not the disk access still happens). Please attach the .trace file for the responsible process.

Thanks!

Interesting: what it's spending most of its time doing is polling sda. In fact, both of the traces look the same: they're both polling sda over and over again. It may not matter which one I kill first; the beeping doesn't stop until both hald-addon-storage processes are killed. (The trace I'm attaching is the second trace.)

On this machine, sda is a built-in USB-based memory stick reader. The reader is seen at boot time, but there is no stick in the reader so there's only sda, no sda1.

The desktop machine also has a built-in USB flash card reader (one of those N-in-one gizmos, for which I had to modify the udev conf so it could mount cards when the're inserted). So it's quite possible the same USB polling was going on on the desktop, and that may explain why not everyone sees this behavior. (That and the fact that it happens to make a noise on this laptop and flash the light on the desktop.)

It looks like I was totally wrong about it being the IDE hard disk; it's a USB issue after all. Though I don't understand why the hard disk access light on my desktop was flashing regularly until I killed hald. I don't think the HD icon on the laptop is flashing, but it's hard to tell since it's often hard to see if it only flashes quickly. I wonder if the desktop motherboard could be flashing its disk light for USB accesses, or something weird like that?

Akkana, thank you for your outstanding help to track this down. Indeed it seems that your motherboard flashes the light for USB access and your IDE drive is never touched at all.

So actually everything seems to work just as it's meant to be. The polling is done to automatically mount media in removable media devices like CD-ROMs or your card reader. This is at least necessary for IDE CD-ROMs. Out of interest, if you kill the two hal helpers, does automounting of inserted media still work for your USB flash reader?

Inserted media aren't automounted even with the two hal devices polling; running hald makes no difference I've been able to notice.

Is automounting dependent on the gnome desktop doing something? I've done a lot of this testing without any desktop running -- in fact, on the Dapper Flight 6 I've been using to test this, running the desktop hangs the machine (no keyboard response, no network response, no flashing keyboard lights, have to unplug the power cord and restart) about two times out of three, so I had to disable it. The hald polling and beeping happens whether or not I run the gnome desktop.

The /dev/sda device is created correctly and mounts correctly whether or not the hald processes are running, or indeed even if I aptitude purge the whole hald package.

Is there really never going to be a way to disable polling multiple times a second? Is removing hald the only solution for people who don't want all this polling and aren't getting any benefit from it?

> Is automounting dependent on the gnome desktop doing something?

Yes, it must be running (specificall, gnome-volume-manager needs to be
running) to actually automount stuff. Hal does not mount itself, it
just provides information about the hardware.

> I've done a lot of this testing without any desktop running -- in
> fact, on the Dapper Flight 6 I've been using to test this, running
> the desktop hangs the machine (no keyboard response, no network
> response, no flashing keyboard lights, have to unplug the power cord
> and restart) about two times out of three, so I had to disable it.

Ouch, that sounds really serious; are these bugs known in Malone?

> The /dev/sda device is created correctly and mounts correctly
> whether or not the hald processes are running, or indeed even if I
> aptitude purge the whole hald package.

Yes, hal is just required for automatically mounting them.

> Is there really never going to be a way to disable polling multiple
> times a second?

There is a way, you need to disable the polling in
e. g. /etc/hal/fdi/policy/preferences.fdi, but it's not really user
friendly to do that.

User friendly or not, I'd appreciate instructions on how to do it. I tried changing everything I could find that looked like it might be related (see the first couple comments in this bug) but nothing I could find stopped the polling. In hoary it was possible to get hald to stop polling by editing a file, but it doesn't seem to work in either breezy or dapper.

> Ouch, that sounds really serious; are these bugs known in Malone?

I haven't had much luck in the past reporting X and kernel hangs, but I see there's a similar bug reported for the ATI driver (though no one's looking into it yet), so I've reported mine (Savage) as bug 41340.

/etc/hal/fdi/policy/preferences.fdi has an example for that. Try something like

  <device>
    <match key="storage.hotpluggable" bool="false">
        <merge key="storage.automount_enabled_hint" type="bool">false</merge>
    </match>
    <match key="storage.removable" bool="false">
        <merge key="storage.automount_enabled_hint" type="bool">false</merge>
    </match>
  </device>

Frankly, I'm puzzled what to do about this bug report now. hal does what it's supposed to do, and disabling polling would disable the automount feature for CD-ROMs, card readers, and other removable devices. Do you have any suggestions?

Nope. Neither your example, nor the example that's already in the file (which is different: it nests the storage.removable case inside the storage.hotpluggable case) stops the polling. If anything it might be more frequent after making the change. (Yes, I did also uncomment the lines, and I'm rebooting between changes, not just manually restarting processes.)

As to what to do about the bug and whether it's still a bug, I don't have a problem with automount (and even polling, if that's truly the only way the kernel can do automount) being on by default. But there are still some bugs left (IMHO, of course):

1. There should be a way to actually stop the polling. Currently, the file says it's possible but the lines in the file don't actually seem to change anything -- surely that counts as a bug?

2. Is it really necessary to have two daemons doing a seemingly identical poll, once a second (or so) each? Couldn't one daemon handle it, and at least cut down the polling by half?

3. Isn't a polling interval of twice a second (or even once a second) rather aggressive? Does hal not allow any possibility of tuning the polling interval?

If a way is found to change the polling, I'd even argue that both the interval, and whether to poll at all, would make an excellent addition to one of the sysadmin menus. I bet lots of people don't know that frequent polling is going on, and would disable it or at least scale the interval longer if they knew. But that's more an RFE than a bug, and commandline ways of controlling this (short of sudo aptitude purge hald) would be plenty to fix this bug.

This bug is nearly 2 years old. Does the issue still exist, or is there now a way to disable polling, customise the polling interval, and/or reduce polling to a single daemon? If not, I believe the priority of this bug should be increased from "low" as it definitely has a negative impact on power saving features on laptops. I don't much care what the default is, but there needs to be an easy to way to customise or disable it.

Hi,
the bug showed in my case to be a problem with the power mangament which
allways spins down the hardrive.
I use ...
sudo hdparm -B 255 /dev/sda to stop that shit ...

bye

hackel schrieb:
> This bug is nearly 2 years old. Does the issue still exist, or is there
> now a way to disable polling, customise the polling interval, and/or
> reduce polling to a single daemon? If not, I believe the priority of
> this bug should be increased from "low" as it definitely has a negative
> impact on power saving features on laptops. I don't much care what the
> default is, but there needs to be an easy to way to customise or disable
> it.
>
>

There is "hal-disable-polling" now, see manpage.

Martin,
Yes, of course hal-disable-polling exists. I guess it wasn't explicitly stated in this bug, but what we need is a generic configuration mechanism to prevent HAL from polling a particular device in the first place. We can't expect all laptop users to figure out how to create a startup script to run hal-disable-polling on their own. Does this exist? If not, then I don't believe this bug is truly "fixed" because it needs to be easy for the average user to change IF they want to sacrifice functionality for the extra battery life.

Since hal itself is an UI-less system daemon, this should then preferably be integrated into the "media" preferences of nautilus.

Aside from any posible future nautilus UI, I'm not seeing from the hal-disable-polling documentation how someone could use it to disable all polling. It looks like you'd have to mount an investigation to figure out which devices were being polled (read the discussion in this bug to see that it's not necessarily straightforward), then write a script to be called at boot time to disable each device one by one.

This bug is asking for a way to say, simply, "don't poll anything". Which hal-disable-polling doesn't seem to provide.

I agree that the UI is a separate issue. What I was wondering was whether hal had this capability already, and after doing a little digging, discovered that it indeed does, and is enabled by default in Ubuntu. For the benefit of anyone else reading this, I'll explain.
(This is from /usr/share/doc/hal/examples/no-cd-media-check.fdi)
All you have to do is create a new .fdi file in /etc/hal/fdi/policy/ like follows:

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="block.device" string="/dev/hdc">
      <merge key="info.addons" type="strlist"></merge>
    </match>
  </device>
</deviceinfo>

Just change the match "string" attribute to match the device you wish to blacklist from hal's polling. Restart hal and voilà!

This option is a sort of "make my computer not work correctly", not really something any non technical user is going to use or that should be in the nautilus interface, closing the nautilus task a won't fix, could be added to some tweaker application rather

Thanks hackel, you made my day. I can once again put my hd to sleep!