Bug 242959 - After upgrade, scheduled actions do not run on client systems
Summary: After upgrade, scheduled actions do not run on client systems
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Upgrades
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Mike McCune
QA Contact: Steve Salevan
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 173432
TreeView+ depends on / blocked
 
Reported: 2007-06-06 17:30 UTC by Steve Salevan
Modified: 2007-10-30 02:42 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-06-07 20:15:43 UTC


Attachments (Terms of Use)

Description Steve Salevan 2007-06-06 17:30:40 UTC
Description of problem:
If a user upgrades an RHN Satellite to 500 and attempts to run a scheduled
action, such as a package install, on a client machine, rhn_check will not pick
up the action.

Version-Release number of selected component (if applicable):
Satellite 500

How reproducible:
Always

Steps to Reproduce:
1.  Upgrade an older satellite to 500 via the rhn-upgrade process
2.  On one of the Satellite's systems, schedule a package install or a remote
action, such as a script
3.  Run rhn_check -vvv on the client system
  
Actual results:
rhn_check reports:

D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: Called refresh_rpmlist
D: local action status:  (0, 'rpmlist refreshed', {})

and does not perform requested actions.

Expected results:
rhn_check indicates that requested actions are being performed and performs them.


Additional info:

Comment 1 Steve Salevan 2007-06-06 17:31:16 UTC
QA Contact -> ssalevan

Comment 2 wes hayutin 2007-06-06 17:53:37 UTC
I also ran into this on 4.1.5 -> 5.0 upgrade

Comment 3 Pradeep Kilambi 2007-06-06 17:54:28 UTC
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 

Comment 4 Steve Salevan 2007-06-06 18:08:21 UTC
Prad:
The client is rlx-0-20.rhndev.redhat.com and the satellite is
fjs-0-14.rhndev.redhat.com.

Comment 5 Pradeep Kilambi 2007-06-06 18:29:35 UTC
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', {})


Comment 6 Pradeep Kilambi 2007-06-06 18:37:36 UTC
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.

Comment 7 wes hayutin 2007-06-06 19:09:24 UTC
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

Comment 8 Steve Salevan 2007-06-07 18:26:48 UTC
Reassigning to mmccune due to this being a front-end bug.

Comment 9 Devan Goodwin 2007-06-07 19:36:07 UTC
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?

Comment 10 Devan Goodwin 2007-06-07 20:11:00 UTC
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.

Comment 11 Devan Goodwin 2007-06-07 20:15:43 UTC
Changing to NOTABUG.


Note You need to log in before you can comment on or make changes to this bug.