Bug 242959

QA Contact -> ssalevan

I also ran into this on 4.1.5 -> 5.0 upgrade

could you point me to the client & sat where you saw this behavior so that i can
play a little to see whats up with it.

thanks
prad 

Prad:
The client is rlx-0-20.rhndev.redhat.com and the satellite is
fjs-0-14.rhndev.redhat.com.

the problem seems to be with osa-dispatcher.. i just tried the following:

- scheduled a package install

- ran rhn_check -vvv

- no effect

- now on server  run $ service osa-dispatcher restart

- now run rhn_check on client and
psutils-1.17-23.i386.rpm:   ########################## Done.                   
D: Package ['psutils', '1.17', '23', '', 'i386', '86297', 'rhel-i386-as-4']
Fetched via: get
Preparing              ########################################### [100%]

Installing...
   1:psutils                ########################################### [100%]
   2:a2ps                   ########################################### [100%]
The following packages were added to your selection to satisfy dependencies:

Name                                    Version        Release
--------------------------------------------------------------
psutils                                 1.17           23                  

D: Sending back response (0, 'Packages were installed successfully', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: Called refresh_rpmlist
D: local action status:  (0, 'rpmlist refreshed', {})

so it is definitely  spicking the action. But its delayed for some reason..

- i jus schedlued a package install of alchemist-devel and waited for 5-10 mins

- ran rhn_check -vvvv
D: Adding to transaction set ['alchemist-devel', '1.0.34', '1', '', 'i386',
'114703', 'rhel-i386-as-4']
D: Checking for dependencies
D: Running transaction (final step)...
D: getPackage ['alchemist-devel', '1.0.34', '1', '', 'i386', '114703',
'rhel-i386-as-4']
alchemist-devel-1.0.34-1.i3 ########################## Done.                   
D: Package ['alchemist-devel', '1.0.34', '1', '', 'i386', '114703',
'rhel-i386-as-4'] Fetched via: get
Preparing              ########################################### [100%]

Installing...
   1:alchemist-devel        ########################################### [100%]
D: Sending back response (0, 'Packages were installed successfully', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: Called refresh_rpmlist
D: local action status:  (0, 'rpmlist refreshed', {})

so looks like a ui thing.. its not adding the action immediately into the queue
once its scheduled.

my sat has the same behavior that Pradeep explains in comment 5,6
If you wait 3-5 minutes before running rhn_check -vvv the actions are picked up
by the client

Reassigning to mmccune due to this being a front-end bug.

The clocks on the two systems in question are slightly off, rlx-0-20 (the
client) is about 4 minutes behind fjs-0-14 (the satellite). When scheduling an
event to occur as soon as possible, the satellite uses it's current time as the
earliest occurrence. The event is scheduled immediately, but the client checks
in and sees a time in the future for this new action. Once it's clock progresses
to the time the satellite scheduled the acton for (3-5 minutes as described
above) the event is able to be picked up.

We could update the UI to start storing NULL instead of the satellite's current
time as the earliest occurrence, then update all client code to interpret this
as "immediately".

However given the situation however the behavior as is seems reasonable to me,
and this fix introduces a one-off situation in the code which is not desirable.
Keeping the system clocks in check should get rid of the problem and not doing
so has the mild side effect of actions being delayed by whatever delta the
clocks are at. Reccommend we leave the behavior as is.

Thoughts or other suggestions?

Looks like the database clock was also running about 5 minutes slow, which will
also cause the event to be delayed. Corrected this clock, as well as the client,
and packages are now installing immediately after scheduling.

Changing to NOTABUG.