Bugzilla – Bug 1216197
testX hangs at second stage
Last modified: 2023-12-14 16:30:29 UTC
On a installation with autoyast testX hangs after the reboot and starting the second stage. 731 tty1 Ss+ 0:00 /bin/bash /usr/lib/YaST2/startup/YaST2.Second-Stage 2391 tty1 S+ 0:00 \_ /bin/bash /usr/lib/YaST2/startup/YaST2.call installation continue 2908 tty7 Ssl+ 0:00 \_ Xorg -noreset -br -nolisten tcp -deferglyphs 16 vt07 2963 tty1 S+ 0:00 \_ /usr/lib/YaST2/bin/testX 2965 tty1 Z+ 0:00 \_ [testX] <defunct> This hangs vorever untill you log in via ssh and kill the mother process (here pid 2963 Don't know it is also siginificant for Yast2 and the installation process
Created attachment 870142 [details] y2start.log y2start log with hanging textX
testX seems to hang, wenn no windowmanager is available. In my opinion it should fail and exit 1. But it simply hangs.
Indeed it should exit. And it did that all the time; the code is unchanged since 11 years. https://github.com/yast/yast-x11/blob/master/src/tools/testX.c In your case, the child process exited, but remained as a zombie process ("<defunct>", "Z+" in the 'pstree' output), i.e. the kernel is waiting for the parent process to do a 'wait' for the process to collect its exit status. But it does call 'waitpid()'.
Calling code: https://github.com/yast/yast-installation/blob/master/startup/YaST2.call#L33-L71 In the attached y2start.log, we see Stage [call]: Check selected medium... Stage [call]: ======================== |-- Wished medium is: QT |-- Selected medium is: QT |-- TestX: XOpenDisplay failed |-- TestX: XOpenDisplay failed I.e. 'testX' exited with 1 twice, i.e. the X server wasn't ready yet to accept a connection. In the case of a VNC installation (which this was not), the YaST2.call script only tries this once, otherwise it tries it up to 15 times: https://github.com/yast/yast-installation/blob/master/startup/YaST2.call#L257 wait_for_x11 15 Since we see a child process in the 'pstree' output, it must hang somewhere in 'RunWindowManager()': https://github.com/yast/yast-x11/blob/master/src/tools/testX.c#L184-L206 Since the child process exited, it obviously could start none of 'icewm', 'fvwm2', 'mwm', 'twm'; which is not surprising since very likely none of them is installed. So it exited with 0, and the parent process should have picked up that exit status since all it ever did was to wait with 'waitpid()' for that child process to exit.
Daniel, is this reproducable, or was it a one-time problem?
Hi STefan, I can reproduce it on a coreI5 machine here at my office and had the same problem on a Core i7 machine at a customer (Intel NUC NUC11PHKi7C), but the NUC is in CHina so not under my control.
OK, thanks. That leaves me wondering what's wrong here. The 'waitpid()' call with the WNOHANG flag may return prematurely if the parent process is much faster than the child process (which would be quite normal since it tries several 'exec..()' calls before exiting). That's also a bit broken, but not in a way that this should hang; to the contrary, in that case the parent process will exit immediately, the child process will be orphaned, and it will be picked up by 'init' which in such a case always does a 'wait()' call to avoid zombie processes filling up the process table. But quite obviously the parent process hangs, and I don't see where else it could hang.
If you have an idea how to debug this.....I can reproduce it any time.
Draft fix: https://github.com/yast/yast-x11/pull/29
Created attachment 870331 [details] ZIP file with a new testX binary from the draft fix Unzip and move the testX binary to /usr/lib/YaST2/bin/testX
Daniel, could you test this version? You can either build it from source from the https://github.com/yast/yast-x11/tree/huha-fix-testx branch, or simply unzip and move the attachment from comment #10; whichever you prefer.
Building from source: git clone -o upstream git@github.com:yast/yast-x11.git git checkout -b huha-fix-testx upstream/huha-fix-testx make -f Makefile.cvs make && sudo make install Needed packages: grep BuildRequires package/*.spec BuildRequires: autoconf BuildRequires: automake BuildRequires: gcc-c++ BuildRequires: libtool BuildRequires: xorg-x11-libX11-devel BuildRequires: xorg-x11-libXmu-devel BuildRequires: yast2-devtools >= 3.1.10 i.e. sudo zypper in autoconf automake gcc-c++ libtool xorg-x11-libX11-devel xorg-x11-libXmu-devel yast2-devtools
Hello Stefan, thanks, it seems to work. After copying it to the system and a reboot, the Xorg server starts and the graphical yast did his work. If you need further informations, please let me know. Regards Daniel
Okay, thanks for testing this!
SR / MR to SLE-15-SP5 as yast2-x11-4.5.2: https://build.suse.de/request/show/311275 Maintenance team, please notice: This does not need to become an installer self-update since only an optional second stage of the installation is affected, with for most products only affects AutoYaST scenarios where a second stage is explicitly requested.
More detailed information in the PR: https://github.com/yast/yast-x11/pull/29/files Merge PRs to SLE-15-SP6 and finally to master / Factory are on the way.
Merge to SLE-15-SP6 (as yast2-x11-4.6.2): https://github.com/yast/yast-x11/pull/31 SR to IBS SLE-15-SP6: https://build.suse.de/request/show/311286
SUSE-RU-2023:4860-1: An update that has one fix can now be installed. Category: recommended (moderate) Bug References: 1216197 Sources used: openSUSE Leap 15.5 (src): yast2-x11-4.5.2-150500.3.5.1 Basesystem Module 15-SP5 (src): yast2-x11-4.5.2-150500.3.5.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.