http://bugzilla.opensuse.org/show_bug.cgi?id=1045658 Bug ID: 1045658 Summary: yast2 services-manager is very slow after 3.1.44 update Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers@suse.de Reporter: adaugherity@tamu.edu QA Contact: jsrain@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14 Build Identifier: On my most recent autoyast installation, I noticed it appeared to hang in the 2nd stage after auth-client had finished, but it eventually unfroze and finished successfully. Inspecting the YaST logs, I see that it was services-manager at fault, as it took 3m45s to run! Launching services-manager in the installed system is likewise very slow, taking about 47 seconds every time (6 seconds to launch, then 41 seconds while "Reading services status..." is displayed). If I roll back to yast2-services-manager-3.1.43, then it launches much quicker, in about 9 seconds (6 to launch + 3 reading status). Reproducible: Always Steps to Reproduce: 1. Install yast2-services-manager-3.1.44 update or enable the updates repo during [auto]installation. 2. Launch YaST2 services-manager. 3. Go grab some coffee... Actual Results: services-manager takes 47 sec to launch, or 3:45 to run during autoinstallation. Expected Results: services-manager should launch in < 10 sec, as it did before. Perhaps the systemctl calls added in this update may be the bottleneck? It takes a fraction of a second for each, but does several hundred of them... ==== 2017-06-22 17:45:05 <1> nfs-next(9284) [liby2] genericfrontend.cc(main):617 Launched YaST2 component 'y2base' 'services-manager' 'ncurses' 2017-06-22 17:45:05 <1> nfs-next(9284) [ui-component] YUIComponentCreator.cc(createInternal):124 Creating UI component for "" 2017-06-22 17:45:05 <1> nfs-next(9284) [liby2] genericfrontend.cc(main):806 YAST_IS_RUNNING is yes 2017-06-22 17:45:05 <1> nfs-next(9284) [Ruby] yast/wfm.rb:211 Call client /usr/share/YaST2/clients/services-manager.rb [...] 2017-06-22 17:45:05 <1> nfs-next(9284) [Ruby] yast2/systemd_unit.rb:122 `systemctl show multi-user.target --property=AllowIsolate --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath ` 2017-06-22 17:45:06 <1> nfs-next(9284) [Ruby] yast2/systemd_unit.rb:122 `systemctl show basic.target --property=AllowIsolate --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath ` 2017-06-22 17:45:06 <1> nfs-next(9284) [Ruby] yast2/systemd_unit.rb:122 `systemctl is-enabled basic.target ` 2017-06-22 17:45:06 <1> nfs-next(9284) [Ruby] yast2/systemd_unit.rb:122 `systemctl show bluetooth.target --property=AllowIsolate --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath ` [...] 2017-06-22 17:45:51 <1> nfs-next(9284) [Ruby] yast2/systemd_unit.rb:122 `systemctl show user@0.service --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath ` 2017-06-22 17:45:51 <1> nfs-next(9284) [Ruby] yast2/systemd_unit.rb:122 `systemctl is-enabled user@0.service ` ==== Strangely, if I extract all these systemctl commands to a shell script, and run 'time systemctl.sh', it runs in 5.97 seconds. Does that mean the overhead is actually in YaST or ruby instead of systemctl? -- You are receiving this mail because: You are on the CC list for the bug.