This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 242959 - After upgrade, scheduled actions do not run on client systems
After upgrade, scheduled actions do not run on client systems
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Upgrades (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Mike McCune
Steve Salevan
:
Depends On:
Blocks: 173432
  Show dependency treegraph
 
Reported: 2007-06-06 13:30 EDT by Steve Salevan
Modified: 2007-10-29 22:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-07 16:15:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Steve Salevan 2007-06-06 13:30:40 EDT
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 13:31:16 EDT
QA Contact -> ssalevan
Comment 2 wes hayutin 2007-06-06 13:53:37 EDT
I also ran into this on 4.1.5 -> 5.0 upgrade
Comment 3 Pradeep Kilambi 2007-06-06 13:54:28 EDT
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 14:08:21 EDT
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 14:29:35 EDT
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 14:37:36 EDT
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 15:09:24 EDT
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 14:26:48 EDT
Reassigning to mmccune due to this being a front-end bug.
Comment 9 Devan Goodwin 2007-06-07 15:36:07 EDT
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 16:11:00 EDT
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 16:15:43 EDT
Changing to NOTABUG.

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