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?