Could not reproduce this on RHEL 8. /var/log/tlsetup.log shows: > 2020-06-29 13:10:14,714: Installing service 'vsmserver'... > 2020-06-29 13:10:14,799: Output (stderr): > 2020-06-29 13:10:14,799: Failed to execute operation: Access denied > 2020-06-29 13:10:14,799: Failed to install service 'vsmserver Checking the status manually for any of the services will return: 'Failed to get properties: Access denied' Running 'systemctl daemon-reexec' seems to fix this issue.
Even though this is fixed now, this bug was caused by switching to systemd for our services (See bug 4290).
As a note that this indeed seems to be an older systemd requirement; the openssh-server package on RHEL 7 has a daemon-reload call, but not the same package on Fedora 31. The change can be found here: https://github.com/systemd/systemd/commit/873e413323dfff4023604849c70944674ae5cd29#diff-bb28816fe894df9a1253db8a8b6b9f14
Patch looks mostly ok. But it's missing "|| true" on the calls. Without that we might get problems if systemctl is in a bad mood, and this call is just a hint.
Seems to work fine now. Tested upgrade from 4.11.0 to latest Jenkins build, and fresh install of the Jenkins build, on RHEL 7, RHEL 8 and Ubuntu 20.04. No issues whatsoever. Status of services looked fine even between installing/upgrading packages and running tl-setup. Also tried uninstalling on RHEL 8 and Ubuntu 20.04 and didn't see anything bad.
Testing on RHEL 8 server. I could reproduce this error upgrading from 4.11.0 -> 4.12.0. Running 'systemctl daemon-reexec' indeed fixes this. 4.11 -> nightly build 6527 works great though. Services looks fine after upgrading packages and also after tl-setup. Tested that I could connect with native client/webaccess and that services looked good on webadmin page. Also tested the same after a fresh install using nightly build 6527 on: - RHEL 7 - RHEL 8 - Ubuntu 20.04 Relnotes looks good.
A platform specific note has also been added so users can work around this issue until the next release.
