Description of problem: 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 Completed in Spacewalk. So, any subsequent actions do not get picked up unless an rhn_check is manually done on the client. 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). Version-Release number of selected component (if applicable): spacewalk-config-2.2.2-1.el6.noarch spacewalk-monitoring-selinux-2.2.1-1.el6.noarch spacewalk-backend-config-files-common-2.2.43-1.el6.noarch spacewalk-backend-iss-export-2.2.43-1.el6.noarch spacewalk-selinux-2.2.1-1.el6.noarch spacewalk-doc-indexes-2.2.2-1.el6.noarch spacewalk-backend-sql-2.2.43-1.el6.noarch spacewalk-taskomatic-2.2.123-1.el6.noarch spacewalk-monitoring-2.2.1-1.el6.noarch spacewalk-backend-tools-2.2.43-1.el6.noarch spacewalk-branding-2.2.5-1.el6.noarch spacewalk-utils-2.2.25-1.el6.noarch spacewalk-base-minimal-2.2.33-1.el6.noarch spacewalk-backend-libs-2.2.43-1.el6.noarch spacewalk-java-config-2.2.123-1.el6.noarch spacewalk-backend-server-2.2.43-1.el6.noarch spacewalk-backend-app-2.2.43-1.el6.noarch spacewalk-backend-config-files-2.2.43-1.el6.noarch spacewalk-backend-iss-2.2.43-1.el6.noarch spacewalk-pxt-2.2.33-1.el6.noarch spacewalk-schema-2.2.33-1.el6.noarch spacewalk-sniglets-2.2.33-1.el6.noarch spacewalk-html-2.2.33-1.el6.noarch spacewalk-java-2.2.123-1.el6.noarch spacewalk-slf4j-1.6.1-6.el6.noarch spacewalk-certs-tools-2.2.1-1.el6.noarch spacewalk-backend-xml-export-libs-2.2.43-1.el6.noarch spacewalk-backend-config-files-tool-2.2.43-1.el6.noarch spacewalk-backend-package-push-server-2.2.43-1.el6.noarch spacewalk-base-2.2.33-1.el6.noarch spacewalk-setup-2.2.13-1.el6.noarch spacewalk-grail-2.2.33-1.el6.noarch spacewalk-common-2.2.2-1.el6.noarch spacewalk-jpp-workaround-2.2.3-1.el6.noarch rhn-org-httpd-ssl-key-pair-spacewalk-qa-1.0-1.noarch spacewalk-java-oracle-2.2.123-1.el6.noarch spacewalk-backend-sql-oracle-2.2.43-1.el6.noarch spacewalk-java-lib-2.2.123-1.el6.noarch spacewalk-admin-2.2.5-1.el6.noarch spacewalk-oracle-2.2.2-1.el6.noarch spacewalk-backend-2.2.43-1.el6.noarch spacewalk-backend-xmlrpc-2.2.43-1.el6.noarch spacewalk-backend-applet-2.2.43-1.el6.noarch spacewalk-base-minimal-config-2.2.33-1.el6.noarch spacewalk-search-2.2.8-1.el6.noarch spacewalk-repo-2.2-1.el6.noarch spacewalk-setup-jabberd-2.0.1-1.el6.noarch 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.
What I see is: ====================================================================== Summary: System reboot scheduled by admin Details: This action will be executed after 10/30/14 6:00:00 AM EDT This action's status is: Completed. The client picked up this action on 10/30/14 11:02 AM The client completed this action on 10/30/14 4:48 PM Client execution returned "null" (code null) Time: 10/30/14 6:00:00 AM EDT ====================================================================== I scheduled the reboot action on WebUI at: 10/30/14 6:00:00 AM EDT I manually run rhn_check on the client at: 10/30/14 11:02 AM (we need to unify the timestamp format), so the reboot action was picked up and the reboot happened within 3 minutes Next rhn_check was run by the rhnsd daemon at: 10/30/14 4:48 PM (when the action was marked as completed.) The action completes. Unfortunately not right after the reboot, but with the upcoming rhn_check. The situation is not ideal, we know about the behavior, but we have no better solution for that. See https://www.redhat.com/archives/spacewalk-list/2014-October/msg00259.html for more information. For now I'm closing the BZ as WONTFIX. (As a workaround you may decrease the INTERVAL value in /etc/sysconfig/rhn/rhnsd file on the client machine and restart rhnsd service. The value represents number of minutes, how often rhn_check shall be run. But be careful with changing the value. The more client machines you have registered to the Spacewalk server, the bigger should be the value.)
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.