problem with hal-0.2.97.cvs20040823-1.i386.rpm

[Jef Spaleta]

Anyone seen the haldaemon initscript from hal-0.2.97.cvs20040823-1.i386.rpm
taking a cup of coffee or longer length of time to return when run? 

The hanging happens at boot up if haldeamon is enabled
And by hand after bootup with haldaemon is disabled at boot up.

I've reverted back to hal-0.2.97.cvs20040819-1.i386.rpm  and I can't
reproduce the problem.

And here's the kicker.... if i have hal-0.2.97.cvs20040819 daemon
running when i try to install
hal-0.2.97.cvs20040823  the package install process stalls as well
since whatever  the post/pre (un)install script being activated in
that process makes a call to service haldaemon which hangs just like i
see at boot up with hal-0.2.97.cvs20040819 installed.  Very not
cool.... very not not cool when this happens during a yum update and
stopping yum leaving the system with duplicate packages installed
since yum's transaction didn't complete.

Anyone else seeing this? Before I dig into the script logic looking
for a smoking gun?

-jef

[Mike Chambers]

On Tue, 2004-08-24 at 21:22 -0400, Jeff Spaleta wrote:
>  Anyone seen the haldaemon initscript from
> hal-0.2.97.cvs20040823-1.i386.rpm
>  taking a cup of coffee or longer length of time to return when run? 
>  
>  The hanging happens at boot up if haldeamon is enabled
>  And by hand after bootup with haldaemon is disabled at boot up. 
Just now experienced the same thing and turning off haldaemon let's it
boot/continue.

Although, I also ran into rhgb not wanting to run now with kernel .525
or .526.  Of course, this was after latest rawhide updates as of this
morning.

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt...Then it's hilarious!"

[Oldman]

On Tue, 2004-08-24 at 22:19 -0500, Mike Chambers wrote:
>  On Tue, 2004-08-24 at 21:22 -0400, Jeff Spaleta wrote:
>  > Anyone seen the haldaemon initscript from hal-0.2.97.cvs20040823-1.i386.rpm
>  > taking a cup of coffee or longer length of time to return when run? 
>  > 
>  > The hanging happens at boot up if haldeamon is enabled
>  > And by hand after bootup with haldaemon is disabled at boot up.
>  
>  Just now experienced the same thing and turning off haldaemon let's it
>  boot/continue.
>  
>  Although, I also ran into rhgb not wanting to run now with kernel .525
>  or .526.  Of course, this was after latest rawhide updates as of this
>  morning. 
	I have problems with rhgb, but it looks to me that the problem is with
the transfer to XORG, as if I wait long enough, I do get to log in to my
account but then I can't change screen modes at all. even switching to a
console is not possible, as the console appears as the top 1/3 of my
screen in 5 columns (all unreadable, of course).

I filed a bugzilla at 
https://freedesktop.org/bugzilla/show_bug.cgi?id=1175 


>  Mike Chambers
>  Madisonville, KY
>  
>  "It's only funny until someone gets hurt...Then it's hilarious!"
>  
>

[Richard Hally]

Jeff Spaleta wrote:

> Anyone seen the haldaemon initscript from
> hal-0.2.97.cvs20040823-1.i386.rpm
> taking a cup of coffee or longer length of time to return when run? 
>
> The hanging happens at boot up if haldeamon is enabled
> And by hand after bootup with haldaemon is disabled at boot up.
>
> I've reverted back to hal-0.2.97.cvs20040819-1.i386.rpm  and I can't
> reproduce the problem.
>
> And here's the kicker.... if i have hal-0.2.97.cvs20040819 daemon
> running when i try to install
> hal-0.2.97.cvs20040823  the package install process stalls as well
> since whatever  the post/pre (un)install script being activated in
> that process makes a call to service haldaemon which hangs just like i
> see at boot up with hal-0.2.97.cvs20040819 installed.  Very not
> cool.... very not not cool when this happens during a yum update and
> stopping yum leaving the system with duplicate packages installed
> since yum's transaction didn't complete.
>
> Anyone else seeing this? Before I dig into the script logic looking
> for a smoking gun?
>
> -jef
>
>
>   
>  
Yup, screwed up my 'yum update'. Now I don't know what states the 
packages are in or  how to recover.
Jeff you wanted breakage. Please be careful what you wish for...
Richard Hally

[David Zeuthen]

Hi,

On Tue, 2004-08-24 at 21:22 -0400, Jeff Spaleta wrote:
>  Anyone seen the haldaemon initscript from
> hal-0.2.97.cvs20040823-1.i386.rpm
>  taking a cup of coffee or longer length of time to return when run? 
>  
>  The hanging happens at boot up if haldeamon is enabled
>  And by hand after bootup with haldaemon is disabled at boot up.
>  
>  I've reverted back to hal-0.2.97.cvs20040819-1.i386.rpm  and I can't
>  reproduce the problem.
>  
>  And here's the kicker.... if i have hal-0.2.97.cvs20040819 daemon
>  running when i try to install
>  hal-0.2.97.cvs20040823  the package install process stalls as well
>  since whatever  the post/pre (un)install script being activated in
>  that process makes a call to service haldaemon which hangs just like i
>  see at boot up with hal-0.2.97.cvs20040819 installed.  Very not
>  cool.... very not not cool when this happens during a yum update and
>  stopping yum leaving the system with duplicate packages installed
>  since yum's transaction didn't complete.
>  
>  Anyone else seeing this? Before I dig into the script logic looking
>  for a smoking gun?
>   
Anyone who identifies this problem, please file a bug against with hal
with the output of 

 'HALD_VERBOSE=1 /usr/sbin/hald --daemon=no'

running as root while having installed the latest .cvs20040823. Also
attach the output of 'tree /sys'. Ensure there are no hald processes
running before doing this. 

One of the changes that may cause this is that the hald process blocks
until all device probing is complete. I will change that back so we
daemonize immediately as a stopgap solution.

Thanks,
David

[David Zeuthen]

On Wed, 2004-08-25 at 10:07 +0200, David Zeuthen wrote:
>  > Anyone else seeing this? Before I dig into the script logic
> looking
>  > for a smoking gun?
>  > 
>  
>  Anyone who identifies this problem, please file a bug against with hal
>  with the output of 
>  
>   'HALD_VERBOSE=1 /usr/sbin/hald --daemon=no'
>  
>  running as root while having installed the latest .cvs20040823. Also
>  attach the output of 'tree /sys'. Ensure there are no hald processes
>  running before doing this. 
>  
>  One of the changes that may cause this is that the hald process blocks
>  until all device probing is complete. I will change that back so we
>  daemonize immediately as a stopgap solution.
>   
Alright, I've built a new hal-0.2.97.cvs20040823-3, not sure it will
make todays upload, maybe, we'll see. One way to work around this with
the .cvs20040823-1 package is to 'pkill hald' if your update hangs.

For the technically inclined, the bug was that hald forks at startup and
the parent sits and wait for the child to send a message through a pipe
to signal device detection is completed. Obviously this fails if the
child dies, then the parent just sits there. The child may die for a
multitude of reasons including the system message bus not being up.
Sorry about that.

Hope this helps,
David

[Steve G]

> Obviously this fails if the child dies, then the parent just sits
> there. 
> The child may die for a multitude of reasons including the system message 
> bus not being up. 
You can still do this in a variey of ways. I usually use a signal pipe that's
written to by a sigchld handler and then do a select across all the pipes of
interest. One of the programs I've been looking at recently, udev or dbus, does
this, too. Xinetd is also another example of this technique.

-Steve Grubb


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush