[Spacewalk-list] Schedule Reboot (Spacewalk 2.2 bug?)

[Coffman, Anthony J]

I can confirm this behavior on my install (2.2).  The reboot action completes but isn’t marked as completed until rhn_check runs.

I’m using Ansible to forcibly run rhn_check so I haven’t run into the 2nd part where no future actions are picked up.

Regards,
--Tony


From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Matthew Madey
Sent: Monday, October 6, 2014 8:18 PM
To: spacewalk-list at redhat.com
Subject: [Spacewalk-list] Schedule Reboot (Spacewalk 2.2 bug?)

Hey all,

I've recently upgraded one of our Spacewalk environments from 2.0 to 2.2, following the instructions found here: https://fedorahosted.org/spacewalk/wiki/HowToUpgrade
I first upgraded to 2.1, rebooted all systems (Spacewalk core, database server, and proxies), then upgraded to 2.2, rebooted all systems (Spacewalk core, database server, and proxies). The Spacewalk Server AND Spacewalk Proxies were upgraded to v2.2

Everything appeared to be working just fine, until I noticed a strange issue with Scheduling reboots.

When I schedule a system reboot, the client picks up the action immediately (using OSAD), and schedules the reboot appropriately for 3 minutes in the future. The system successfully reboots, however, that reboot action is NEVER marked as complete in Spacewalk. So, any subsequent actions do not get picked up unless an rhn_check is manually done on the system. After that, the reboot action is marked completed and all subsequent actions are picked up normally. Also, after the system reboots, if I go to the schedule tab and cancel that reboot action, all subsequent actions are picked up without issue. I've tested this with the same results in QA at work (RHEL 6.5 clients), as well as in my home lab (CentOS 6.5 clients). Has anyone else noticed this issue? I'd like to see if I'm missing something before filing a bug report..

Steps I've taken already:

1. Set verbosity to level 5 on osad.conf for the client. Everything looks fine in the logs until after the reboot, when the server starts and the OSAD service starts, it's not checking in with Spacewalk even though OSA status says online.

2. Stop OSAD, remove /etc/sysconfig/rhn/osad-auth.conf, start OSAD. Same results. Reboot action is picked up immediately, and the system reboots successfully, but the action is never marked Completed.

3. Stopped jabberd on the Spacewalk proxy the client is connected to, cleared jabberd database, and restarted jabberd. I've done the same on the Spacewalk server, and tried them in different orders as well.

4. Manually running a shutdown -r now on the client. THIS WORKS. When the system comes back up, any queued actions are picked up and executed successfully. This is one of the main reasons it leads me to believe there is an issue with the Schedule reboot API in Spacewalk v2.2 (BTW, I've tried the API via Python script, as well as through the WebUI, same results where the action is never marked Completed).

5. Verified the client is running the latest versions of osad, rhnsd, rhn-client-tools, rhn-setup, and rhn-check from the 2.2 repo

6. Registered the client to a Spacewalk 2.0 environment. Everything works as it should there. No issues.



Has anyone else seen this behavior? Any help would be greatly appreciated. We rely very heavily on the Spacewalk API's as all of our patching is completely automated in Python scripts. It's not a big deal to schedule a remote action to run the shutdown -r command on the clients instead, but if this is a bug I'd like to see it get fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20141007/d18cd439/attachment.htm>