hal 0.4.2 "Something like that. Tastes the same anyway." released

[Sjoerd Simons]

On Thu, Dec 02, 2004 at 10:55:09AM -0500, David Zeuthen wrote:
> On Thu, 2004-12-02 at 13:30 +0100, Sjoerd Simons wrote:
> > On Wed, Dec 01, 2004 at 06:44:10PM -0500, David Zeuthen wrote:
> > > Hey,
> > > 
> > > I just released hal 0.4.2 "Something like that. Tastes the same anyway."
> > > that fixes a number of small bugs; Here are the changes in short form
> > > 
> > >  - Only lazy unmount devices if {storage.volume}.policy.should_mount is
> > >    TRUE - e.g. don't lazy unmount devices we don't care about
> > 
> > Wasn't hal supposed to be policy free ;). 
> 
> Well, yeah - the unmount trick have been in hal for a long time. I agree
> it's somewhat enforcing policy. Ideally, a callout should take care of
> this but I don't want to make such a big change in this stable series.
> 
> The thing is, if we don't do this then the desktop user gets a very
> strange experience if he pulls out a drive that is mounted.
> 
> I hope this is OK - you may just patch it out from Debian if you don't
> like it.

I wasn't complaining about the unmounting. But why have a policy thing decide
which drive to unmount and which not to unmount. As said we don't have hal
itself do the unmounting, but provide an dev.d script to do that. 
> 
> > If i'm correct the should_mount policy
> > item decides whether or not fstab-sync makes an entry in fstab or is there a
> > deeper meaning ? 
> > 
> 
> It can, and should, be used by policy mount wrappers as well. Basically,
> the should_mount property says whether we should mount things or not.
> This is configurable by the distributor and user in a nice way.

Wasn't that what storage.automount_enabled_hint was for ? At least
debian/ubuntu's gvm is patched to honor this one..
> 
> You will note that in the general policy we set should_mount to FALSE
> for SCSI drives mostly to avoid dealing with "big iron" boxes that has
> several hundreds or several thousands of disks attached to them. Because
> right now hal is not mature enough to handle that correctly. 

In debian/ubuntu there also hasn't been a decision/solution yet how to handle
non-removable drives. Currently with pmount we just do removable drives. 
> 
> Note that when Kay's wonderful hotplug and udev work (see linux-hotplug
> archives) lands we can change hal to "do the right thing" because we
> don't have to listen to two streams of event (e.g. the hotplug.d and
> dev.d), we don't need to reorder events, and we don't have to have
> complicated logic for dealing with missing events. Things will get
> *much* simpler. 

I know. Kay rocks :)
> 
> Also, my plan is to move all IO (expect for sysfs) out to separate
> processes (fs detection, polling for media, link detection, ACPI battery
> monitoring, PMU battery monitoring, whatever etc.) that is invoked by
> hald - said processed will use libhal to speak to hald. 

Cool

> That will solve the nasty issues with hald hanging in state D
> (uninterruptible sleep). Instead, on kernel bugs, we will just have
> lingering helper processes hanging in state D which is much better than
> hald hanging in that state. (yes, this means one separate process per
> drive we are polling).
> 
> Also, moving IO to separate processes has the benefit that it's *much*
> easier lock down what each separate processes is allowed to do (on a
> non-selinux systems these are just setuid root, drop privs and only
> executable by the hald process).

Exactly.. We're going the right way here imho :). The one process per drive
also makes sense here. New drive is plugged in, spawn watcher, drop permission
and all is nice. But if you really have lots of drives, it might be overkill.  
> 
> Btw, the motivation for this particular change (only unmount drives we
> care about, e.g. not SCSI drives), was actually that some people with
> hundreds and hundreds of disks got bitten by hal unmounting their SCSI
> disks because there was a race condition in hald which means that the
> hotplug event for "remove /dev/sdq3" was processed 45 minutes after we
> received it. In the meantime the user had of course mounted it and then
> we went ahead and unmounted fun. That was fun.

That was the one i was fishing for :) Sounds like a nasty bug.. As hal doesn't
do the unmounting for us, we don't have that problem (anymore..).
> 
> I hope this clarifies. I also hope you like my plan above.

Yeah, sounds great. Looking forward to it.
> 
> > For debian we use a little script in dev.d to lazy unmount volumes (hal
> > doesn't run as root). Basically if the device disappears, there is no use
> > in keeping it mounted right?
> 
> I agree with you but I'm sure that sysadmins of large machines will
> probably come up with some *fun* corner cases where this is dangerous. I
> could be wrong though.

I would be interested in those corner cases, if any. I fished for some on the
linux-hotplug list, but got no reactions. For now i don't know why one would
install hal on a big (server) machine, but this could change in the future.

  Sjoerd
-- 
Not every question deserves an answer.
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal