Hi to all,
I am a new user from suse manager.
I did register an instance on ssm and subscribed it to a channel.
I created a script which schedule a reboot action for a bunch of server, but I noticed that the action doesn’t perform at the time that I set up.
I noticed that the scheduleReboot operations, occurs almost [COLOR="#000000"]five hours later[/COLOR] since my scheduled time.
Here there is an example.
I set up the scheduleReboot at [COLOR="#000000"]9/26/15 4:31:00 PM BST[/COLOR] ,
but the in Completed System tab on ssm it said that it completed at [COLOR="#000000"]9/26/15 8:37:58 PM BST [/COLOR]
And also other systems, which have had the schedulereboot action setup runs almost 4/5 hours later.
Can somebody explain me if this is the correct behaviour from ssm or there is something which I am missing???
Normally when you schedule things you will see the field in the web UI
shows, “no earlier than”, because what normally happens is that rhn_check
needs to be run to actually check for something to do. This command, by
default, runs every four (4) hours, so normally your command may run
anywhere from right at the time scheduled (if rhn_check happens to run
right then) or else within four hours, but it could be as soon as one hour
(the minimum interval for the rhn_check service to run) to much longer (if
you change it to refresh less-often).
If you want it to run more-quickly, look into the osad (pronounced OH-suh
DEE) service which can then register for events more-quickly, though there
are limits to how many systems to which you push events at once since if
you push 100 MB of stuff to 500 boxes at once, you’re talking about 50 GB
of traffic, plus load on the PostgreSQL instance, with all of the
network/disk activity associated. I think I’ve heard 300 is a good number
to have at the high end for that particular option, though mitigating this
is partially why rhn_check only runs once per hour at most.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Hi Ab and thanks for the suggestion.
I did run the rhn_check -vvv from the client and the schedulereboot action have been invoked as expected.
Unfortunately there is a problem. (I think so, but not sure)
After that action have been executed, on ssm the schedulereboot action is still listed in the tab ‘pending action’ and not in the ‘completed action’
I was expecting to this action to be insert in the tab action completed.
Is there somethings that I missed, or even if I force the client to run the action scheduled, ssm will move the action to the complete tab only when the time that I scheduled before is passed?
I hope that I have been clear on my last question
Hi Ab,
I found the answer to my question so don’t worry
I have a question. Is possible to call the rhn_check or the osa-dispatcher from the suse-manager api?
I found no documentation about that.
Cheers
I’m not completely sure what you are asking, but I think you’re asking if,
from SUSE Manager (SUMA), you can force the rhn_check call without waiting
for an interval. This is what I was referring to previously; you can
either change from the rhnsd service (which runs rhn_check every four
hours by default, and is configurable via the /etc/sysconfig/rhn/rhnsd
file allowing you to change the default 240 to as low as 60 (no, do NOT go
lower as it will not accept it and will default back to 240)), then
restarting the rhnsd service to apply the change, or you can enable osad
(the client side of osa-dispatcher) in order to allow on-demand pushes.
If you install the rhncfg-actions package as well, particularly during
initialization of the client box in the SUMA environment to avoid needing
to add permissions to the client box for remote commands. Once done you
could kick of rhn_check from the SUMA web UI after scheduling whatever,
and that command would be executed on the selected system(s) for you
without needing to SSH/access every one in another way, which is nice.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Hi Ab and thanks for the explanation.
You got what I was asking for, but this solution is not suitable for me,
My script just needs to makes api calls from SUMA and access to the instances could create security problems
and also I am rely on SUMA for the action’s results.
I founded a work around for my problem.
Thanks for your help
