Bugzilla – Bug 798620
systemctl hangs in 2nd stage
Last modified: 2021-03-09 12:13:36 UTC
openQA.o.o found that since today yast2 2nd stage hangs > ps ax 4079 tty1 Sl+ 0:08 y2base installation ("continue") qt --noborder --auto-fonts --fullscreen 4084 tty1 S+ 0:00 dbus-launch --autolaunch 98d2ecfbcf5c97e4baa0585150f529ed --binary-syntax --close-stderr 4085 ? Ss 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 4240 tty1 S+ 0:00 /usr/bin/perl -w /usr/lib/YaST2/servers_non_y2/ag_udev_persistent 4337 tty1 S+ 0:00 y2base installation ("continue") qt --noborder --auto-fonts --fullscreen 4338 tty1 S+ 0:00 y2base installation ("continue") qt --noborder --auto-fonts --fullscreen 4339 tty1 S+ 0:00 /bin/systemctl start SuSEfirewall2.service 4340 tty1 S+ 0:00 /usr/bin/systemd-tty-ask-password-agent --watch likely appears now because of changes for bug 795929
can be worked around by pressing ctrl-alt-f2 and running killall systemctl a few times
this is pretty similar to old 12.2 bug 774754
could YaST call systemctl with the value of SYSTEMCTL_OPTIONS, just like the change we did for aaa_base : /usr/bin/systemctl ${SYSTEMCTL_OPTIONS} <name_of_the_action> <service_name> ?
https://github.com/yast/yast-yast2/blob/2303d930e20ccebcdfcb9e8516d9ff9108616289/library/runlevel/src/Service.ycp#L296 That's exactly where you want to add things. But where is $SYSTEMCTL_OPTIONS coming from and what should it be?
this time SuSEfirewall2.service is an actual service file. the NO_WRAP workaround to start SuSEfirewall2 without systemd knowing wont help anymore. The question is why does systemctl hang here but doesn't in the running system?
(In reply to comment #5) > this time SuSEfirewall2.service is an actual service file. the NO_WRAP > workaround to start SuSEfirewall2 without systemd knowing wont help anymore. > The question is why does systemctl hang here but doesn't in the running system? which is why I introduced SYSTEMCTL_OPTIONS, so we can ensure services are still wrapped with systemd but we can "tweak" how they are started (I've just pushed a patch for YaST to ensure it uses SYSTEMCTL_OPTIONS when calling systemctl. The blocking is coming from systemctl, which was waiting for SuSEfirewall2.service to be started. By default, systemd will wait until the services AND its dependencies are started. But unfortunately, YaST is starting the network itself, not through network.service, which is causing systemd is "block" until network.service is started (it is in the queue to be started, but only after YaST-Second-Stage is done). Some logic has been added to systemd to "merge" calls like this, but it looks like it doesn't merge the additional parameter (ignore-dependencies). This is something I need to discuss with upstream. So far, the "fix" is to : - ensure YaST will use SYSTEMCTL_OPTIONS, when set, to call systemctl - stop SuSEfirewall2.service in ExecStartPre in YaST-Second-Stage.service (no fonctional change, since the firewall was supposed to be started after / during Second Stage), so this call is removed from the activation queue in systemd
the hotfixes we added to yast packages this morning work for beta1
the hang in 2nd stage came back after Beta1
hotfix got removed by latest yast2 submission in Factory. Unfortunately, YaST team didn't accept my fix so I had to push it to systemd itself (and it was refused upstream too). I'll push a fixed systemd in Base:System and Factory today.
This is an autogenerated message for OBS integration: This bug (798620) was mentioned in https://build.opensuse.org/request/show/149704 Factory / systemd https://build.opensuse.org/request/show/149705 Factory / systemd
hotfix in yast2-installation was also removed :( I've just sent a pull request for it (it was forgotten).
This is an autogenerated message for OBS integration: This bug (798620) was mentioned in https://build.opensuse.org/request/show/149708 Factory / yast2-installation
I have started RC1 with ssh=1. The problem is still there. 2nd stage only continues after killing systemctl.
(In reply to comment #13) > I have started RC1 with ssh=1. The problem is still there. 2nd stage only > continues after killing systemctl. The problem with 2nd stage hanging is also there without ssh (and text mode). No more details available here because I couldn't switch to another console. Both tests done in virtualbox.
You seem to be the only who sees the problem still with RC1 - which is rather strange as you seem to be able to reproduce it. Possibly it's related to VB or your package selection. Anything interesting in the system log?
It's architecture related. I have tested graphical x86_64 installation in virtualbox and it worked. After the reboot the X-Server started and the installation finished. i586 installation in virtualbox doesn't work, the X-Server doesn't start after reboot (like described in bnc #799480, comment #15) and the system hangs, see screen shot.
Created attachment 525198 [details] screen shot after reboot
I guess the virtualbox issue should be tracked on bnc#799480 and this bug should be closed.
*** Bug 820696 has been marked as a duplicate of this bug. ***
This is an autogenerated message for OBS integration: This bug (798620) was mentioned in https://build.opensuse.org/request/show/195868 Factory / yast2
According to comments, it looks like this comment should be closed. Gabriele, since we are cleaning up the bugzilla database today, can you please close it if you agree? Thanks.
Marked as duplicate of Virtualbox problem bnc#799480. *** This bug has been marked as a duplicate of bug 799480 ***
For the record, the change in comment 20 was https://github.com/yast/yast-yast2/pull/98 in Git.