Reboot node remotely

[Thomas A. Williams]

We have a need to reboot nodes via CA Scheduler. The scheduler calls a DCL procedure which is ultimately making this call:

@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN NO YES SHORTLY YES REBOOT

The problem is this call seems to die prematurely before the reboot is able to complete.

Any ideas on how to reliably make a remote call and reboot a node?

[Robert Gezelter]

Thomas,

I would suspect that something is dying before the actual shutdown takes place.

I generally reboot through DECnet SET HOST or TCP telnet sessions. No problem. Have you tried SYSMAN or a batch job? (I would reboot one of my systems in the lab, but they are busy with things at this instant).

- Bob Gezelter, http://www.rlgsc.com

[labadie_1]

Not a batch job (shutdown stops the queue manager, so the job itself !), but a detached process works fine.

[Thomas A. Williams]

let me try the batch queue.

How do you mean to use SYSMAN to reboot?

[Jan van den Ende]

Thomas,

from your Forum Profile:


I have assigned points to of responses to my questions.

One of these dates back to 2005.

Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.

Thanks on behalf of your Forum colleagues.

PS. - nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before - please do not take offence - none is intended!

PPS. - Zero points for this.

Proost.

Have one on me.

jpe

[Thomas A. Williams]

>Not a batch job (shutdown stops the queue manager, so the job itself !), but a detached process works fine.

how exactly would you run that? I tried spawn/nowait but that didn't seem to work.

[Heinz W Genhart]

Hi Thomas

I atteched a commandfile, which can solve your problem.

I hope it helps

Regards

Heinz

[Hoff]

One of my favorites for this is a one-liner inside of SYSMAN, specifically SYSMAN SHUTDOWN:

http://h71000.www7.hp.com/doc/83final/6048/6048pro_082.html#startsubcommand_497

This deals with it all for you.

[Thomas A. Williams]

>Hi Thomas

>I atteched a commandfile, which can solve your problem.

I hope it helps

Regards

Heinz

==========================

Heinz - that actually worked quite well, except for that fact that it was a shutdown instead of a reboot. I'm gonna look to tweaking it to a reboot.

[Heinz W Genhart]

Hi Thomas

you have only to change a line within the commandfile. Search for the Label "$run_detached:"
After this, there are two symbol definitions, one for shutdown and one for reboot

$run_detached:
$ SHUTDOWN == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN NO YES LATER NO NONE"
$ REBOOT == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN NO YES LATER YES REB"
$ REPL/ALL/BEL/URGENT "Detached SHUTDOWN of ''F$GETSYI("NODENAME")'. PID is ''F$GETJPI("","PID")'"
$! delete this $ SHUTDOWN
$ reboot ! add this

The commandfile is only a framework, which shows a possible solution for your problem. You may want to change some things in this framework.

Hope that helps

Regards

Heinz

[Thomas A. Williams]

Heinz, can you possibly repost that script so that it reboots instead of just shuts down. I find myself unable to mod it enough to reboot successfully.

I owe you a beer or 10 if you can get that to work for me. Thanks Much.

[Hoff]

Try SYSMAN> SHUTDOWN.

It deals will all this stuff for you, uses typical DCL qualifiers, and it runs SHUTDOWN in the appropriate context on whatever node you aim it at.

The other approach is via the older AMDS or the newer Availability Manager tools. If you don't have these loaded and enabled on your nodes, you're missing out on some very useful tools. These can deal with critical remote management, and can remotely manage a node for basic operations -- even when the node is wedged.

As for the DCL procedure, the commands shown can also be derived from the default system manager LOGIN.COM, FWIW.

[Heinz W Genhart]

Hi Tomas

you can find the reboot commandfile as an attachement


... and Hoff is right. This would do the job as well. My solution is from the 'old' days.

Regards

Heinz

[Wim Van den Wyngaert]

Just tried Hoff's method. The shutdown stops (runs in a subprocess of FMI server which is stopped by us). So it could fail at your site too.

I would go for Geni command procedure which runs detached. But add "remove_node" to the @ line because we have nodes with complicated voting schemas (not what I should do but I can't modiffy it).

Wim

[Thomas A. Williams]

Thanks Hoff. That last com file worked great. If you're ever in NYC post here and I'll buy you some rounds!

[Heinz W Genhart]

Hi Thomas

nice to hear that the commandfile I (not Hoff) posted solves your problem.

In your forum profile I found the following

I have assigned points to 25 of 100 responses to my questions.

Maybe you can find some time to assign some points ....


Regards

Heinz

[Thomas A. Williams]

I did assign points.

[Wim Van den Wyngaert]

Try again. I think you didn't press "submit points" (at the bottom).

Wim

[Hoff]

re: NYC?
NYMLUG local user's group meeting, tentatively scheduled 28-Feb-2007. Details:
http://groups.yahoo.com/group/NYMLUG/

[Hoff]

>>> Just tried Hoff's method. The shutdown stops (runs in a subprocess of FMI server which is stopped by us). So it could fail at your site too. <<<

The SHUTDOWN processing occurring after the SMI server SHUTDOWN has started should not be deleting itself or the SMI server itself, and the shutdown is expected to run to completion. If that's not working, it's a bug in (probably) SHUTDOWN.COM. (All that is going on here is that SYSMAN is running SHUTDOWN.COM for you.)

Here assuming you are not stopping SMI server in your local processing.

[EdgarZamora_1]

We moved away from using SYSMAN to shutdown nodes because we encountered problems with SMISERVER being killed (and not by us) during the shutdown process. We didn't really investigate deeply so I can't say if it happened all the time, or was due to specific options chosen, etc.