YaST2 runlevel editor hangs at "28%" on "ag_initscripts" in openSuSE 11.3...

English Applications
#1

Never had this occur with my handy 'lil Yastie before:

Both the text-based & QT YaST “System Services” RunLevel editors hang at 28% when loading the various service runlevel data.

ps -ef | grep YaST2

shows that both:

/usr/lib/YaST2/servers_non_y2/ag_initscripts
/usr/lib/YaST2/bin/y2base runlevel qt

are running…

Killing the “ag_initscripts” allows the QT application to start (sans the runlevel info in either the simple or expert mode).

Not sure why it dies so sadly (QT’s “Abort” button is hard locked too)…

Ideally, I’d like to understand how to manually isolate the cause from the rc?.d perspective, but, any ideas/help is appreciated !! Thanks

#2

The runlevel editor is running all the init scripts with the “status” parameter. It looks like one of the scripts is misbehaving. Run this command to see which one it is:

pstree -pluan `pgrep y2base`
#3

Thanks mvidner, but the above pstree merely shows the same info in my first post (ag_initscripts is hanging)… I need a way to identify where/why the YaST2 runlevel script is hanging.

Nice use of pstree tho !!

y2base,5845 runlevel qt
  ├─{y2base},5846
  └─ag_initscripts,5851 /usr/lib/YaST2/servers_non_y2/ag_initscripts

So I’m still at square-one, ag_initscripts is hanging (running the script as root at the CL has the same effect), no clue to why tho…

The script has a FS date of earlier this new year (I hit a “rpm -Uvh --force” to see if there had been some corruption/config problem earlier),

-rwxr-xr-x 1 root root 9463 2011-01-07 01:15 ./ag_initscripts

The header shows:

#!/bin/bash

# File:         ag_initscripts
# Package:      yast2
# Summary:      Agent for reading initscripts info
# Authors:      Martin Vidner <mvidner@suse.cz>
#               Petr Blahos <pblahos@suse.cz>
#
# $Id: ag_initscripts 57294 2009-05-22 08:54:19Z mvidner $

Any other ideas how to troubleshoot this one ? I’m game for a buncha fun !!

#4

That’s strange. Sorry I don’t have much time for this as I’m leaving for a vacation, but you could try:

  • verifying that some package is not corrupted, by rpm -Va
  • inserting debug logging into ag_initscripts, by
    “set -x; exec 2>> /root/ag_initscripts.log”