Bug 129679

Well, the init script reports correctly, so this probably is an issue with the
runlevel editor of yast.

Can you please attach the /var/log/YaST2 directory (as a tar file)?
Please take a look at http://www.opensuse.org/Bug_Reporting_FAQ#YaST
if you have any problems.

I would really appreciate having those log files.
Thanks

_It seems there are two bugs reported_:

1st: Runlevel editor stucks when checking the "cron" service
2nd: Runlevel editor reports cron "on*" although it is stopped

_Explanation of these bugs_:

1st: Runlevel editor checks many services in the alphabetical order, however if you use the Simple Mode, there are many services between autoyast and cron hidden (see the Expert Mode), these services have to be checked too and it seems that the program stucked.

2nd: This is a small missunderstanding. There is on "on/off*" but Enabled:Yes/No, which means whether the service is enabled in the boot scripts. See the help on the left side: An asterisk (*) after a service status means that the service is enabled but not running or is disabled but running now.

_Solution_:
1st: I'll try to speed it up.
2nd: There's nothing to fix...

Created attachment 56125 [details]
Patch fixing the speed problem

This is a patch which should fix the speed problem. Runlevel editor checks services which are listed in the table and skips which aren't.

If you switch the `simple / `expert mode, it should reread services which were not checked.

Please, try this patch if you like to, with commands:
cd /usr/share/YaST2/include/runlevel;
patch < $whereis_the_file/runlevel_patch_129679.diff

It should be much more faster now....

Fixed in SVN, It will go to the next release AlphaX of SuSE Linux 10.1.

*** Bug 132211 has been marked as a duplicate of this bug. ***

The a.m. patch was tested, but it still hangs on some runlevel elements *and* it does not respond to mouse-clicks anymore.

On which ones does it hang? Do they respond properly in your system?
For instance for "cron" command: `/etc/init.d/cron status` etc.

Do you have YaST logs?
Is it allways reproducible?

Yes, up to now it is always reproducable. This is the end of the log, please note the time until I killed the process!

2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'E' used for YRadioButton "&Einfacher Modus"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'E' used for YRadioButton "&Expertenmodus"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'S' used for YComboBox "&Standard-Runlevel nach dem Systemstart setzen auf:"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'B' used for YCheckBox "&B"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'S' used for YCheckBox "&S"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'S' used for YMenuButton "&Starten/Anhalten/Aktualisieren"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'Z' used for YMenuButton "Anwenden/&Zurücksetzen"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'Z' used for YQWizardButton "&Zurück"
2005-11-10 10:03:41 <1> southpole(6701) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):82 Shortcut conflict: 'B' used for YQWizardButton "&Beenden"
2005-11-10 10:03:41 <1> southpole(6701) [qt-ui] YQCheckBox.cc(stateChanged):151 old: 2; new: 2
2005-11-10 10:03:41 <1> southpole(6701) [qt-ui] YQCheckBox.cc(stateChanged):151 old: 2; new: 2
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript SuSEfirewall2_init status
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript boot.cleanup status
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript boot.clock status
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript boot.coldplug status
2005-11-10 10:03:41 <3> southpole(6701) [bash] ShellCommand.cc(shellcommand):78 ..dead
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript boot.crypto status
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript boot.device-mapper status
2005-11-10 10:03:41 <1> southpole(6701) [YCP] Service.ycp:277 Running service initscript boot.idedma status
2005-11-10 10:55:18 <2> southpole(6701) [qt-ui] YQUI_core.cc(qMessageHandler):640 qt-warning: qt: Fatal IO error: client killed

Your last service checked was 'boot.idedma', could you, please check commands:

/etc/init.d/boot.idedma status
/etc/init.d/boot.ipconfig status
/etc/init.d/boot.isapnp status

Or if you have other service after the boot.idedma - alphabetically sorted in the /etc/init.d/ directory.

looks like the boot.idedma hangs at the CD-Writer:

southpole:/home/axel # /etc/init.d/boot.idedma status
IDE DMA mode status:

/dev/hda:
 using_dma    =  1 (on)

/dev/hdc:
 using_dma    =  1 (on)

<here it hangs>

Hardware:
Probing IDE interface ide0...
hda: HDS722540VLAT20, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 80418240 sectors (41174 MB) w/1794KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4
Probing IDE interface ide1...
hdc: ATAPI DVD-ROM 16XMax, ATAPI CD/DVD-ROM drive
hdd: ATAPI CD-RW 52XMax, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
ACPI: CPU0 (power states: C1[C1])
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdd: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)

In this case, it seems, that the problem lies in the /etc/init.d/boot.idedma script or somewhere below this layer. Author of the script is: lslezak. See the comment #11 and the comment #12.

Axel: thanks for your testings so far.

Mvidner: We could think about using background-agent (with timeout) for Service.ycp - for checking services to prevent from getting stucked. What do you think? (I'd be able to do that).

(In reply to comment #13)
It would be useful for the runlevel editor.
However we would have to be extra careful if we wanted to replace existing Service::* functions. The interface would have to remain the same and you must not forget the other usage modes: autoyast and CLI.

Axel, could you attach output of 'hdparm -d /dev/hdd' command? If it hangs it's HW or kernel bug...

Indeed it was hanging when I tried first time, I could also not access the CD-writer. After a reboot it worked normal - also the runlevel editor. On the other hand, I was not using the CD today, as long as the PC was turned on.

Created attachment 57005 [details]
this is y2 log capturing actions from runleveleditor

I started runlevel and at corn it halts for about 3 minutes.

Here is my y2log.

That seems to be yet another problem in yet another script, see:

2005-11-10 20:49:04 <1> centraal(23958) [YCP] Service.ycp:277 Running service initscript boot.preload_early status
2005-11-10 20:52:07 <3> centraal(23958) [ui] YTable.cc(itemWithId):258 Table: No item "boot.preload_early" existing

I'd guess that running the `/etc/init.d/boot.preload_early status` command stucked the system for 3 minutes. Henk, could you, please, confirm that by running the command on your console?

(The error message 'Table: No item "boot.preload_early" existing' only says that there is no such item in the table. That's fixes my patch in comment #5)

He, That worked!
I'll implement patch from comment #5.

Thanks,
Henk

Yes, sure, that worked because this patch prevents simple runlevel configuration from reading unseen services, but expert configuration would get stucked either. Because it calls the script `/etc/init.d/boot.preload_early status` which probably hangs.

Could you try to run that script please?

/etc/init.d/boot.preload_early unconditionally calls /usr/bin/update_preload, which does not hang but takes a long time.
That also explains why the preloading is done also at shutdown... yuck.

the update_preload only does something if the package database changed. But if that's the only remaining bug here, then this is a duplicate of 117023

Summary: hdparm hang in comment #12 is WORKSFORME (see comment #16), the preload problem is duplicate of bug #117023.

The only thing which remains is to protect yast from hanging - use the background agent (comment #13).

Author of the Service.ycp is mvidner@suse.de, he should decide about using .background agent for that.

On the other hand I could implement it myself then ;)

Maybe OT, but related to comment #12: Device hdd produces error messages like

kernel: hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
kernel: hdd: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
kernel: ide: failed opcode was: unknown

even if the drive is not in use. Is this a kernel issue? I'm running 2.6.13-15.ck6.SUPER.1-default

I suggest not to touch service (at least initially) and use the background agent only for RLE.

Axel: this might not be OT but I just don't know.

Leaving as enhancement: Change Runlevel Editor to check services with the .backgroud agent with timeout.

Stano, what do you think of this enhancement?

yast2-runlevel needs to implement its own function (duplicate for Service.ycp) checking whether the service is running or not - using the background agent with a timeout.

Agreed.

Please, remove me from the CC list. (BTW I don't know where to do that)

Removing reporters mail.

Fixing in SVN for 10.1
Added a new function with time-out after 60 sec.
Runlevel Editor shouldn't stuck now (just for that mentioned 60 sec as maximum ;)).