Description of problem: Provision RHEL4~RHEL6, and log in these system. [root@dev-kvm-guest-07 ~]# chkconfig --list rhts-compat rhts-compat 0:off 1:off 2:off 3:off 4:off 5:off 6:off Version-Release number of selected component (if applicable): develop How reproducible: 100% Steps to Reproduce: 1.Provision one system with distro RHEL4~RHEL6 2.Log in the system 3.chkconfig --list rhts-compat Actual results: [root@dev-kvm-guest-07 ~]# chkconfig --list rhts-compat rhts-compat 0:off 1:off 2:off 3:off 4:off 5:off 6:off Expected results: [root@dev-kvm-guest-07 ~]# chkconfig --list rhts-compat rhts-compat 0:off 1:off 2:off 3:on 4:on 5:on 6:off Additional info:
Just a note that this is not a regression caused by the fix to BZ#1012452 .
I asked Bill Peck about this, and rhts-compat tinkers with the tty settings on the system so that legacy tests think they're running with a valid tty. However, having rhts-compat running isn't compatible with logging in via the system console, so it appears /distribution/reservesys shuts down the rhts components. I'll do some additional checking while working on bug 894159, but for now, closing this as expected behaviour when reserving the system.
It occurs to me that a better way to test this without risking interference from /distribution/reservesys would be to actually run a test case using /distribution/command that checked the state of chkconfig --list rhts-compat when reservesys *wasn't* running. The main point Bill made was that tasks and recipes can request for rhts-compat to be switched off and on, so it's not just a matter of provisioning a system through the scheduler and then logging in to check the current state.
(In reply to Nick Coghlan from comment #6) > It occurs to me that a better way to test this without risking interference > from /distribution/reservesys would be to actually run a test case using > /distribution/command that checked the state of chkconfig --list rhts-compat > when reservesys *wasn't* running. That's a good idea. That will allow us to check the state when we don't change the boot state of rhts-compat.
(In reply to Amit Saha from comment #7) > (In reply to Nick Coghlan from comment #6) > > It occurs to me that a better way to test this without risking interference > > from /distribution/reservesys would be to actually run a test case using > > /distribution/command that checked the state of chkconfig --list rhts-compat > > when reservesys *wasn't* running. > > That's a good idea. That will allow us to check the state when we don't > change the boot state of rhts-compat. Turns out to be: rhts-compat 0:off 1:off 2:off 3:on 4:on 5:on 6:off