hal forks many hald-addon-storage processes

[David Zeuthen]

On Thu, 2006-09-07 at 09:30 +0300, David Peer wrote:
> Hi,
> 
> I have some SunFire X4100 servers that run Debian on it.
> When dbus loads hald, hald-runner forks 9 hald-addon-storage process 

I'm curious why that happens. We only fork a hald-addon-storage add-on
if the storage device got removable media. It sounds weird that you
would have 9 devices that accepts removable media on such a box.

So, what is the hardware setup and hal version? 

Also, for one of the devices that hald-addon-storage touches, let's
assume it's /dev/sda, what's the output of 

 $ cat /sys/block/sda/removable

Can you also attach the output of lshal?

> which cuase cpu load when the machine should be idle.
> I've check it when they where "dead" = machine complitly idle!

Huh? Basically, each of these processes just do

 while (TRUE) {
     fd = open ("/dev/sd?", O_RDONLY);
     close (fd);
     sleep (2);
 }

to poll for media changes so if this puts a huge load on the machine
it's a bug with the driver and/or hardware. 

Mind you, we've seen instances where some USB host controller driver
went haywire - IIRC this was caused by a bad USB board - look at the
archives of this list.

> How can I limit those child processes to one process? 

No, this wouldn't be safe. 

We used to poll from one process but if a driver goes haywire and puts
the polling process in state D (uninteruptible IO) it's game over for
the whole process. This used to happen a lot in early Linux 2.6 but it's
much better now. 

> or disable 
> hald-addon-storage from loading?

Not something you want either. 

It looks to me like you have issues with either the driver or the
hardware itself. But I would need to look at lshal output to make sure.
It may suck to hear this but on the upside it means that maybe someone
gets to fix a driver and many people will benefit from this bug report
of yours. Thanks.

    David