From: Scott Lurndal on
neilsolent <n(a)solenttechnology.co.uk> writes:
>
>> =A0I challenge you to name _one_ commercial 3rd party application that
>> =A0reboots a unix box.
>>
>> scott
>
>OK. Challenge accepted.
>How about IBM Tivoli Framework. The framework daemon has this
>capability.

Tivoli (and Openview, Unicenter, Nagios etc.) are not applications
in the normal sense - they are very specialized monitoring and
control applications; often using IPMI to manage power or reset
managed systems. Most often, such monitoring tools will invoke
a host-system reboot using the IPMI soft-shutdown capability which
injects an ACPI soft-shutdown (buttonpress) event to the Operating
System and the operating system then invokes all the correct procedures
to correctly stop all running applications and processes.

Note that this class of applications generally does not execute on
the system being monitored (other than perhaps a custom SNMP agent
if the stock agent isn't sufficient) and all interactions are through
either IPMI or SNMP traps.

Unless you're developing a similar monitoring and control application,
you probably shouldn't ever consider including a system reboot capability
in your application.

scott
From: David Schwartz on
On Jan 19, 12:52 am, neilsolent <n...(a)solenttechnology.co.uk> wrote:

> >  I challenge you to name _one_ commercial 3rd party application that
> >  reboots a unix box.

> OK. Challenge accepted.
> How about IBM Tivoli Framework. The framework daemon has this
> capability.

And if you had said "I need to reboot a system for similar reasons to
why IBM Tivoli Framework needs to reboot a system" you would have
gotten useful answers. Very often, the right way to do something
depends heavily on why you want to do it. This is one of those cases.
Yet you stubbornly insist that people tell you the right way to do it
when they have no idea what use case you are in, and therefore no way
to know what the right way for you is.

DS
From: neilsolent on
On 19 Jan, 20:06, sc...(a)slp53.sl.home (Scott Lurndal) wrote:
> neilsolent <n...(a)solenttechnology.co.uk> writes:
>
> >> =A0I challenge you to name _one_ commercial 3rd party application that
> >> =A0reboots a unix box.
>
> >> scott
>
> >OK. Challenge accepted.
> >How about IBM Tivoli Framework. The framework daemon has this
> >capability.
>
> Tivoli (and Openview, Unicenter, Nagios etc.) are not applications
> in the normal sense - they are very specialized monitoring and
> control applications; often using IPMI to manage power or reset
> managed systems.   Most often, such monitoring tools will invoke
> a host-system reboot using the IPMI soft-shutdown capability which
> injects an ACPI soft-shutdown (buttonpress) event to the Operating
> System and the operating system then invokes all the correct procedures
> to correctly stop all running applications and processes.
>
> Note that this class of applications generally does not execute on
> the system being monitored (other than perhaps a custom SNMP agent
> if the stock agent isn't sufficient) and all interactions are through
> either IPMI or SNMP traps.

No. That is completely incorrect.
Tivoli framework is a daemon running as root. Process name is lcfd.


>
> Unless you're developing a similar monitoring and control application,
> you probably shouldn't ever consider including a system reboot capability
> in your application.
>
> scott

I am developing a similar monitoring and control application.
From: neilsolent on
On 19 Jan, 22:02, David Schwartz <dav...(a)webmaster.com> wrote:
> On Jan 19, 12:52 am, neilsolent <n...(a)solenttechnology.co.uk> wrote:
>
> > >  I challenge you to name _one_ commercial 3rd party application that
> > >  reboots a unix box.
> > OK. Challenge accepted.
> > How about IBM Tivoli Framework. The framework daemon has this
> > capability.
>
> And if you had said "I need to reboot a system for similar reasons to
> why IBM Tivoli Framework needs to reboot a system" you would have
> gotten useful answers. Very often, the right way to do something
> depends heavily on why you want to do it. This is one of those cases.
> Yet you stubbornly insist that people tell you the right way to do it
> when they have no idea what use case you are in, and therefore no way
> to know what the right way for you is.
>
> DS

OK. I need to reboot a system for similar reasons to why IBM Tivoli
Framework needs to reboot a system.
Can I have my useful answers now ? :-)
From: Rainer Weikusat on
neilsolent <n(a)solenttechnology.co.uk> writes:
> On 19 Jan, 22:02, David Schwartz <dav...(a)webmaster.com> wrote:
>> On Jan 19, 12:52�am, neilsolent <n...(a)solenttechnology.co.uk> wrote:
>> > > �I challenge you to name _one_ commercial 3rd party application that
>> > > �reboots a unix box.
>> > OK. Challenge accepted.
>> > How about IBM Tivoli Framework. The framework daemon has this
>> > capability.
>>
>> And if you had said "I need to reboot a system for similar reasons to
>> why IBM Tivoli Framework needs to reboot a system" you would have
>> gotten useful answers. Very often, the right way to do something
>> depends heavily on why you want to do it. This is one of those cases.
>> Yet you stubbornly insist that people tell you the right way to do it
>> when they have no idea what use case you are in, and therefore no way
>> to know what the right way for you is.

[...]

> OK. I need to reboot a system for similar reasons to why IBM Tivoli
> Framework needs to reboot a system.

If you want this to be (potentially) universally useful, you will need
some kind of extensible 'reboot framework'. What I would do is 'invoke
a script with some well-known name' (or getting the path to the script
from some kind of configuration variable). This allows for easy, local
customization where required. Then, I would write such a script for
each type of system I wanted to support initially and use
another script (or set of scripts) to detect if the application is
about to be installed on a 'supported system' during installation,
with an option for manual override, of course. Depending on the result
of this auto-detection process, the installation code would then
either provide a 'default reboot script' from the library of existing
reboot scripts and inform the sysadmin about this fact, advising him
to have a look at the default script before trying to use the
reboot-feature or display some kind of message which informs the
person doing the install that 'reboot' is not yet supported on this
particular system, because a script actually doing the reboot still
needs to be written, possibly giving a pointer to documentation which
explains the requirements for such a script in sufficient detail to
implement it. Lastly, I would add an 'if you do implement a generally
useful reboot script for system xyz and want to be nice to others,
please mail it to <email address>' message.