Bugzilla – Bug 1056937
Plymouth does not terminate properly
Last modified: 2019-08-14 10:18:12 UTC
Happens occasionally, example: https://openqa.opensuse.org/tests/480391#step/multi_users_dm/24 The artifacts are remnants of the animated openSUSE dots plymouth theme. They are still animated while in the X session. The systemd journal contains "Started Terminate Plymouth Boot Screen." so this is a bug in plymouth.
Do you mean it occasionally fails at the step of: "Installation -> first_boot"?
Oh, the test URL is broken as it got removed after the storage failure on openQA... Newer example: https://openqa.opensuse.org/tests/488011#step/multi_users_dm/23 (In reply to Zhao Qiang 赵强 from comment #1) > Do you mean it occasionally fails at the step of: "Installation -> > first_boot"? No, it happens after "systemctl isolate multi-user.target; systemctl isolate graphical.target".
In the latest run of openQA, this case still failed. https://openqa.opensuse.org/tests/493580#step/multi_users_dm/15 so luckily, I can get the virtual machine image to do the further investment. I think this case failed most because "could not sync environment to dbus." Refer to: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/47 If we try to replace "systemctl isolate graphical.target" to "systemctl start graphical.target", everything goes well. it indicates that action "isolate" lost some necessary work which needs to be finished. I suppose we can make some work on Systemd to fix that. You said that "They are still animated while in the X session.", that is caused of Xwindows and Plymouth try to use VT in a race situation. This case works fine in the latest test. and when I run it offline, it also works fine.
Command "isolate" starts the target unit named name and all dependent units and immediately stops all others. But "start" will *not* stop others. I think that is the point.
(In reply to Zhao Qiang 赵强 from comment #3) > In the latest run of openQA, this case still failed. > https://openqa.opensuse.org/tests/493580#step/multi_users_dm/15 > so luckily, I can get the virtual machine image to do the further investment. > > I think this case failed most because "could not sync environment to dbus." > Refer to: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/47 > If we try to replace "systemctl isolate graphical.target" to "systemctl > start graphical.target", everything goes well. it indicates that action > "isolate" lost some necessary work which needs to be finished. I suppose we > can make some work on Systemd to fix that. I debugged this a bit and found: > Starting Show Plymouth Boot Screen... > Started Show Plymouth Boot Screen. > Starting X Display Manager... which means systemctl isolate graphical.target does actually start plymouth-start.service for some reason. I can't see it in systemctl list-dependencies though, only under sysinit.target which shouldn't be touched by isolate at all as it's part of both multi-user.target and graphical.target. > You said that "They are still animated while in the X session.", that is > caused of Xwindows and Plymouth try to use VT in a race situation. This case > works fine in the latest test. and when I run it offline, it also works fine. Yes, it's likely a race as it does not happen in all cases. It can't happen if plymouth weren't running.
(In reply to Fabian Vogt from comment #5) > (In reply to Zhao Qiang 赵强 from comment #3) > > which means systemctl isolate graphical.target does actually start > plymouth-start.service for some reason. I can't see it in systemctl > list-dependencies though, only under sysinit.target which shouldn't be > touched by isolate at all as it's part of both multi-user.target and > graphical.target. > Do you mean that "systemctl isolate graphic.target" trigger plymouth start but "systemctl start graphic.target" didn't do that?
(In reply to Zhao Qiang 赵强 from comment #6) > (In reply to Fabian Vogt from comment #5) > > (In reply to Zhao Qiang 赵强 from comment #3) > > > > which means systemctl isolate graphical.target does actually start > > plymouth-start.service for some reason. I can't see it in systemctl > > list-dependencies though, only under sysinit.target which shouldn't be > > touched by isolate at all as it's part of both multi-user.target and > > graphical.target. > > > Do you mean that "systemctl isolate graphic.target" trigger plymouth start > but "systemctl start graphic.target" didn't do that? I did not try systemctl start graphical.target, but isolate does result in a start of plymouth-start for some reason.
(In reply to Fabian Vogt from comment #7) > (In reply to Zhao Qiang 赵强 from comment #6) > > (In reply to Fabian Vogt from comment #5) > > > (In reply to Zhao Qiang 赵强 from comment #3) > > I did not try systemctl start graphical.target, but isolate does result in a > start of plymouth-start for some reason. Even it makes result in Plymouth be mistaken started, it still can not say that fault *Must* happens inside Plymouth. Additionally, when I try to disable/remove Plymouth, this problem still can reproduce.
(In reply to Zhao Qiang 赵强 from comment #8) > (In reply to Fabian Vogt from comment #7) > > (In reply to Zhao Qiang 赵强 from comment #6) > > > (In reply to Fabian Vogt from comment #5) > > > > (In reply to Zhao Qiang 赵强 from comment #3) > > > > I did not try systemctl start graphical.target, but isolate does result in a > > start of plymouth-start for some reason. > > Even it makes result in Plymouth be mistaken started, it still can not say > that fault *Must* happens inside Plymouth. It's indeed not necessarily plymouth itself, but likely somewhere in its .service files. > Additionally, when I try to disable/remove Plymouth, this problem still can > reproduce. You uninstalled plymouth and it still starts? I would say that is impossible. You probably didn't reboot and the daemon was still running in the background.
(In reply to Fabian Vogt from comment #9) > (In reply to Zhao Qiang 赵强 from comment #8) > > (In reply to Fabian Vogt from comment #7) > > > (In reply to Zhao Qiang 赵强 from comment #6) > > > > (In reply to Fabian Vogt from comment #5) > > > > > (In reply to Zhao Qiang 赵强 from comment #3) > > > > > > I did not try systemctl start graphical.target, but isolate does result in a > > > start of plymouth-start for some reason. > > > > Even it makes result in Plymouth be mistaken started, it still can not say > > that fault *Must* happens inside Plymouth. > > It's indeed not necessarily plymouth itself, but likely somewhere in its > .service files. > > > Additionally, when I try to disable/remove Plymouth, this problem still can > > reproduce. > > You uninstalled plymouth and it still starts? I would say that is > impossible. You probably didn't reboot and the daemon was still running in > the background. Maybe there was some mistake between us: The fact is: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/28 runs the same test case. This time, "Plymouth race with Xorg" problem wasn't reproduced, but "systemctl isolate graphic.target" reproduced. This will prove that "isolate" problem can be produced *separately*. I mean when I disable/remove Plymouth, "isolate" problem is still there. The main target of this case is want to confirm if multi-user target and graphic target can be switched smoothly, So I want to discuss this problem here. Yes! I will say that "race" is indeed a problem, I never deny this fact. but It will be solved after "isolate" problem be fixed. Because "race" problem only can happen after "isolate" scenario. Another reason is in current situation, we can not say "display manager" or Xwindows is beyond of doubled(even we uninstalled Plymouth, X can't switch well) Regards!
(In reply to Fabian Vogt from comment #9) > (In reply to Zhao Qiang 赵强 from comment #8) > > (In reply to Fabian Vogt from comment #7) > > > (In reply to Zhao Qiang 赵强 from comment #6) > > > > (In reply to Fabian Vogt from comment #5) > > > > > (In reply to Zhao Qiang 赵强 from comment #3) > > > > > > I did not try systemctl start graphical.target, but isolate does result in a > > > start of plymouth-start for some reason. > > > > Even it makes result in Plymouth be mistaken started, it still can not say > > that fault *Must* happens inside Plymouth. > > It's indeed not necessarily plymouth itself, but likely somewhere in its > .service files. > > > Additionally, when I try to disable/remove Plymouth, this problem still can > > reproduce. > > You uninstalled plymouth and it still starts? I would say that is > impossible. You probably didn't reboot and the daemon was still running in > the background. Sorry, I forgot to say, In my words: "disable/remove Plymouth, this problem still can reproduce" "this problem" means: "systemctl isolate graphic.target" can not work problem. :)
The test shows two entirely independent issues: 1) systemctl isolate graphical.target results in a broken DBUS daemon This causes the test to fail and is not relevant here. It's tracked in a different report. 2) Plymouth stays running after isolate graphical.target This is the part of the test that this bug is about. The test run you linked still shows the issue: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/48 It just happened later on that run.
(In reply to Fabian Vogt from comment #12) > The test shows two entirely independent issues: > > 1) systemctl isolate graphical.target results in a broken DBUS daemon > This causes the test to fail and is not relevant here. It's tracked in a > different report. Okay, that's very clear. Could you please show me the bug ID? and has this bug been fixed? > 2) Plymouth stays running after isolate graphical.target > This is the part of the test that this bug is about. > The test run you linked still shows the issue: > https://openqa.opensuse.org/tests/493580#step/multi_users_dm/48 It just > happened later on that run. All staff in Beijing will leave the office for China's National Day till Oct 8. I will invest on this issue at that time, and then, answer your question.
(In reply to Zhao Qiang 赵强 from comment #13) > (In reply to Fabian Vogt from comment #12) > > The test shows two entirely independent issues: > > > > 1) systemctl isolate graphical.target results in a broken DBUS daemon > > This causes the test to fail and is not relevant here. It's tracked in a > > different report. > Okay, that's very clear. > Could you please show me the bug ID? and has this bug been fixed? boo#1020363 - not fixed yet. > > 2) Plymouth stays running after isolate graphical.target > > This is the part of the test that this bug is about. > > The test run you linked still shows the issue: > > https://openqa.opensuse.org/tests/493580#step/multi_users_dm/48 It just > > happened later on that run. > > All staff in Beijing will leave the office for China's National Day till Oct > 8. I will invest on this issue at that time, and then, answer your question. Ok, thanks.
KDE and Plymouth share the same frame-buffer device because Sddm lack of Plymouth controlling logic, A reference is GDM's code: https://github.com/GNOME/gdm/blob/master/daemon/gdm-manager.c#L142-#L208 Additionally, openSUSE is unlike other releases or distros, it boots at tty1 but launch desktop at tty7, this display VT switching makes the "race" problem even more obvious. The modification will add code to quit Plymouth inside Sddm, This problem only effects openSUSE KDE desktop and it doesn't cause the isolate failed or other problem, So I will work in this when I have time. If anyone feels this problem very emergency, please raise the bug priority. Thanks!
(In reply to Zhao Qiang 赵强 from comment #15) > KDE and Plymouth share the same frame-buffer device because Sddm lack of > Plymouth controlling logic, A reference is GDM's code: > https://github.com/GNOME/gdm/blob/master/daemon/gdm-manager.c#L142-#L208 Wrong, it calls plymouth quit in /usr/lib/X11/displaymanagers/sddm The issue is that plymouth is started *after* sddm.
I re-run the process but found that Plymouth started before Sddm, just as expected.
This bug was 2 years long, and till now it can not be reproduced, So closed.