[Spacewalk-list] Schedule Reboot (Bug?)

[William H. ten Bensel]

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 at telenet.be
To:     spacewalk-list at redhat.com
Date:   09/30/2016 10:55 AM
Subject:        Re: [Spacewalk-list] Schedule Reboot (Bug?)
Sent by:        spacewalk-list-bounces at redhat.com



This email originated from outside of the company. Please use discretion 
if opening attachments or clicking on links. 
(sorry for topposting ... webmail)
The way I do it: run rhn_check at boot via cron:

@reboot root /usr/sbin/rhn_check

Franky


Van: "Jeff Baldwin" <JeffB at knowclassic.com>
Aan: spacewalk-list at 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:  
https://www.redhat.com/archives/spacewalk-list/2014-October/msg00067.html
 
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. 
 
https://www.redhat.com/mailman/listinfo/spacewalk-list
This email originated from outside of the company.  Please use discretion 
if opening attachments or clicking on links.

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


**

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.
**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160930/a46734c3/attachment.htm>