Bug 1418738 - rebooting via system event leaves reboot event in "Picked Up" state
Summary: rebooting via system event leaves reboot event in "Picked Up" state
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Client
Version: 580
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Tomáš Kašpárek
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-02 15:24 UTC by Jan Hutař
Modified: 2017-02-03 08:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-03 08:48:23 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jan Hutař 2017-02-02 15:24:51 UTC
Description of problem:
Rebooting RHEL6 server via system even leaves reboot event in "Picked Up" state

Note I have also reported bug 1418737.


Version-Release number of selected component (if applicable):
Satellite: Satellite-5.8-RHEL-6-20170118.0-Satellite-x86_64
Client:
rhn-check-1.0.0.1-38.el6.noarch
rhn-client-tools-1.0.0.1-38.el6.noarch
rhnlib-2.5.22-15.el6.noarch
rhnsd-4.9.3-2.el6.x86_64
rhn-setup-1.0.0.1-38.el6.noarch
yum-rhn-plugin-0.9.1-60.el6.noarch


How reproducible:
1 of 1


Steps to Reproduce:
1. Register server to the satellite, make sure osad is not running
2. On system details page click Schedule System Reboot -> Reboot System
3. # rhn_check -vv
4. Note that system reboot event is marked as "Picked Up"


Actual results:
After 3 minutes system is rebooted. After it boots back, action is still "Picked Up".


Expected results:
Even should be marked as finished


Additional info:
[root@client ~]# rhn_check -vv
D: check_action{'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>reboot.reboot</methodName>\n<params>\n</params>\n</methodCall>\n", 'version': 2, 'id': 639}
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: rpcServer: Calling XMLRPC up2date.login
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at 1486047558.4 with expiration of 1486051158.4 seconds.
successfully retrieved authentication token from up2date server
D: logininfo:{'X-RHN-Server-Id': 1000010109, 'X-RHN-Auth-Server-Time': '1486047557.25', 'X-RHN-Auth': 'U9AxVxhzwQ6zIZQuIhTai4EHpXvSDFbRcTsLt6O5G2o=', 'X-RHN-Auth-Channels': [['rhel-x86_64-server-6', '20170201040913', '1', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
D: handle_action{'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>reboot.reboot</methodName>\n<params>\n</params>\n</methodCall>\n", 'version': 2, 'id': 639}
D: handle_action actionid = 639, version = 2
D: do_call reboot.reboot(){'cache_only': None}
Rebooting the system now
D: Sending back response(0, 'Reboot sucessfully started', {'version': '0'})

Broadcast message from root@client.example.com
	(/dev/pts/0) at 14:59 ...

The system is going down for reboot in 3 minutes!
D: do_call packages.checkNeedUpdate('rhnsd=1',){}
Loaded plugins: product-id, rhnplugin
D: rpcServer: Calling XMLRPC up2date.listChannels
This system is receiving updates from RHN Classic or RHN Satellite.
D: local action status: (0, 'rpm database not modified since last update (or package list recently updated)', {})
D: rpcServer: Calling XMLRPC registration.welcome_message
[root@client ~]# echo $?
0
[root@client ~]# 
Broadcast message from root@client.example.com
	(/dev/pts/0) at 15:00 ...

The system is going down for reboot in 2 minutes!

Broadcast message from root@client.example.com
	(/dev/pts/0) at 15:01 ...

The system is going down for reboot in 1 minute!

Broadcast message from root@client.example.com
	(/dev/pts/0) at 15:02 ...

The system is going down for reboot NOW!
Connection to 192.168.122.25 closed by remote host.
Connection to 192.168.122.25 closed.

Comment 1 Tomas Lestach 2017-02-03 07:52:05 UTC
JanH, what you describe is expected behavior. You need to wait, till rhn_check is run after the reboot to update the action state on the server. If this works, I'd say this is expected behavior.

Comment 2 Jan Hutař 2017-02-03 08:48:23 UTC
Oh my, thanks. You are right.


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