coveralls
commented
2 years ago Coverage remained the same at 39.566% when pulling da6e0cb961d3c0f533ff96004f6df39854fe5f44 on remove_before_xvnc.socket into 4f39711108f3d34daf19aacf2c220c04b2fea5ae on SLE-15-SP3.
yast-bot
This reverts commit 0f3456341afa58b6265fe9217a0ccfcce975ecf9.
Problem
Our recent changes in the services (start after systemd-user-sessiones #1024 and after purge-kernels #1036) probably introduced a bigger window time to connect to the xvnc.socket instance getting a black screen... specially the change about starting after the purge of old kernels will delay the start of our services.
We tried to fix that (see https://bugzilla.suse.com/show_bug.cgi?id=1197265) adding a Before=xvnc.socket dependency which is the behavior we would like to have but as Frank Bui explained YaST2-Second-Stage and YaST2-Firstboot.service can't have DefaultDependencies=yes (implicit setting, which implies After=basic.target) and in the meantime has Before=xvnc.socket (which is ordered before basic.target).
In the bug reported, the ordering cycle problem deletes the systemd-user-sessions.service/start job so it is not run and not privileged users are not able to login the system.
Modifying YaST2-Firstboot and YaST2-Second-Stage to have DefaultDependencies=no introduce other systemd ordering cycle issues so it does not looks like a valid fix.
Solution
By now we have decided to revert changes introduced in #1038 not starting YaST2-Second-Stage and YaST2-Firsboot services before xvnc.socket due to ordering cycle issues. For future releases we could improve the behavior controlling the xvnc.socket enablement during the First Stage of the installation not enabling it until the YaST2-Second-Stage or the YaST2-Firstboot of the installation has finished.
Tests
Tested manually and verified that the same behavior is in previous versions too but the period of time where the xvnc.socket service is up before we start our own Xvnc socket is so small that it is hard to face it.