Franky nailed it. Just some additional insight (do not know how many devices/servers that are supported): If there ever is a chance of mass rebooting 1k+ servers/devices at once, the rhn_check's could degrade the spacewalk. Adding something like the perl command below, will assist in randomizing the rhn_check within xxxx secs of a reboot. @reboot root perl -le 'sleep rand xxxx' && /usr/sbin/rhn_check >& /dev/null Also, if the rpm database becomes corrupt, the system will not check in. - Thanks and good luck From: liedekef@telenet.be To: spacewalk-list@redhat.com Date: 09/30/2016 10:55 AM Subject: Re: [Spacewalk-list] Schedule Reboot (Bug?) Sent by: spacewalk-list-bounces@redhat.com <hr noshade> This email originated from outside of the company. Please use discretion if opening attachments or clicking on links.<hr> (sorry for topposting ... webmail) The way I do it: run rhn_check at boot via cron: @reboot root /usr/sbin/rhn_check Franky <hr> Van: "Jeff Baldwin" <JeffB@knowclassic.com> Aan: spacewalk-list@redhat.com Verzonden: Vrijdag 30 september 2016 16:10:35 Onderwerp: [Spacewalk-list] Schedule Reboot (Bug?) All, I’ve ran into what appears to be an old bug. The issue is that when systems are in ‘Require Reboot’ status, and I reboot them via Spacewalk, the status doesn’t update, even after OSAD has completed the reboot process. I have to run rhn_check to force the status to update. I found that this was discussed in an email back in 2014, but no resolution was mentioned in the thread: <a href="https://www.redhat.com/archives/spacewalk-list/2014-October/msg00067.html" target=_blank>https://www.redhat.com/archives/spacewalk-list/2014-October/msg00067.html</a> The scenario the user described below, still applies perfectly to my 2.5 install (his was 2.2). Are we missing something? 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. <a href="https://www.redhat.com/mailman/listinfo/spacewalk-list">https://www.redhat.com/mailman/listinfo/spacewalk-list</a> <tt>This email originated from outside of the company. Please use discretion if opening attachments or clicking on links. _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com </tt><a href="https://www.redhat.com/mailman/listinfo/spacewalk-list"><tt>https://www.redhat.com/mailman/listinfo/spacewalk-list</tt></a> ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. **