Subject: script mib issue # 20

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jan 2001 18:38:10 +0100

ISSUE 20:

For frontends such as a command line tool to launch scripts, it would
be very useful to have a mechanism which allows to run the script in
the "background" so that the agent automatically cleans up the
smLaunchTable entry when the script results disappear from the
smRunTable.

PROPOSAL:

One possible way to add such a capability is the introduction of a
'onetime(4)' smLaunchAdminStatus value which implies that that the
smLaunchEntry disappears as soon as the first smRunEntry launched from
this launch button disappears. One limitation of this approach is that
you can't have a launch button which is 'autostart' as well as
'onetime'. (But this limitation might be acceptable.)

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Frank Strauss <[email-masked]>
Date: 26 Jan 2001 19:17:30 +0100

Hi!

Juergen> ISSUE 20:

Juergen> For frontends such as a command line tool to launch scripts, it would
Juergen> be very useful to have a mechanism which allows to run the script in
Juergen> the "background" so that the agent automatically cleans up the
Juergen> smLaunchTable entry when the script results disappear from the
Juergen> smRunTable.

Juergen> PROPOSAL:

Juergen> One possible way to add such a capability is the introduction of a
Juergen> 'onetime(4)' smLaunchAdminStatus value which implies that that the
Juergen> smLaunchEntry disappears as soon as the first smRunEntry launched from
Juergen> this launch button disappears. One limitation of this approach is that
Juergen> you can't have a launch button which is 'autostart' as well as
Juergen> 'onetime'. (But this limitation might be acceptable.)

Just a nonrelevant proposal: IMHO, according to the
DISMAN-SCHEDULE-MIB::schedType object, the label `oneshot' instead of
`onetime' would be more consistent.

 -frank

---

From: "Michael J. Slifcak" <[email-masked]>
Date: Fri, 26 Jan 2001 13:35:02 -0500

> `onetime' would be more consistent.

'launchOnce' ?

---

From: Frank Strauss <[email-masked]>
Date: 26 Jan 2001 20:10:06 +0100

Hi!

>> `onetime' would be more consistent.

Michael> 'launchOnce' ?

The schedType object has a value labeled `oneshot' (not `schedOnce').
The semantics of this value and the newly proposed value for the
launchAdminStatus object are comparable (though not really equivalent:
a oneshot schedEntry does not get removed when it's been
invoked). That's why I propose exactly the same name `oneshot' for the
proposed new launchAdminStatus value.

 -frank

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 31 Jan 2001 15:44:09 +0100

> 'onetime'. (But this limitation might be acceptable.)

I see some complications:

Would the Script MIB implementation has to make sure, that after such
a launch entry has been used once, no further runs can be launched from
a onetime entry?

Otherwise it would be possible that more runs are launched while the
first one is running. Then the launch entry cannot be removed after
termination of the first run as you suggested.

I see two solutions:

1. The MIB demands that the smLaunchAdminStatus onetime is only
   allowed if smLaunchMaxRunning is set to 1.

2. Introduce a smLaunchAdminStatus 'autoremove(4)' which indicates
   that the launch entry will be removed automatically, if a script
   launched from this entry terminates AND if no other script lauched
   from this entry is still running.

I prefer solution 2, which is more general. You can implement onetime
runs with solution 2 by setting smLaunchMaxRunning to 1.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Éamonn McManus <[email-masked]>
Date: Wed, 31 Jan 2001 16:14:40 +0100

> > 'onetime'. (But this limitation might be acceptable.)

The problem being solved here is one I ran into in the early days of the
Script MIB.  The client application I wrote had no use for launch
buttons -- all it wanted to do was launch a given script with a given
set of parameters.  Any solutions I could think of risked either
collisions between multiple instances of the application running at the
same time, or launch buttons being left around long after their creators
had died.  The modification being proposed here provides a possible
alternative.  (The modification I proposed at the time was to get rid of
the smLaunchTable altogether, and I'm still not convinced that that
wouldn't be a worthwhile simplification, but let's not go there.)

The main problem that I see with oneshot is that there's no way to clean
up if the client application dies after creating its oneshot button but
before it pushes it.  A possible alternative would be to add an expiry
time to smLaunchTable entries.  An smLaunchTable whose expiry time is
infinite (2^31 - 1) does not expire, as for smRunTable entries.  An
smLaunchTable whose expiry time is finite will disappear as soon as the
time is reached and there are no scripts running from that entry.

> runs with solution 2 by setting smLaunchMaxRunning to 1.

The second solution is indeed more general, but I do not see any use for
the added generality.  The whole idea of oneshot buttons is that there
is exactly one user, who will use it exactly once.  Even if you wanted
to share a oneshot (autoremove) button, you could not do so reliably,
since whether the second user succeeds in pushing the button depends on
how long the first user's script takes to execute, which is
unpredictable.

Éamonn

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 31 Jan 2001 16:27:50 +0100

Éamonn McManus wrote:
 [...]
> > termination of the first run as you suggested.> >
> > I see two solutions:
> >

You are right, some things are unpredictable. My intention was not to
offer a smart multiuser solution, but a one, that uses a simple and general
mechanism instead of a more special one. A 'onetime' status would have
the implication described in solution 1, which IMHO makes the spec and
the implementation of the MIB more complex. A 'autoremove' status would
be easier to specify and implement and it would offer the same funcionality.

    Juergen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Jan 2001 17:37:22 +0100

>>>>> =?iso-8859-1?Q?=C9amonn?= McManus writes:

Eamonn> A possible alternative would be to add an expiry time to
Eamonn> smLaunchTable entries.  An smLaunchTable whose expiry time is
Eamonn> infinite (2^31 - 1) does not expire, as for smRunTable
Eamonn> entries.  An smLaunchTable whose expiry time is finite will
Eamonn> disappear as soon as the time is reached and there are no
Eamonn> scripts running from that entry.

Sounds like a good idea to me. There is one question: What happens if
the timer has expired and someone tries to press the launch button? I
guess we do not want to allow that someone uses a launch button which
has already expired. To do this cleanly, we probably need to add an
'expired(3)' status to the smLaunchOperStatus object...

/js

---

From: Éamonn McManus <[email-masked]>
Date: Wed, 31 Jan 2001 17:53:05 +0100

Juergen Schoenwaelder wrote:
> >>>>> Éamonn McManus writes:

My thinking was that when the expiry time was reached the smLaunchTable
entry would simply disappear without trace.  So if you try to push the
button, you'll get an error because it's no longer there.

Éamonn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Jan 2001 18:02:28 +0100

>> There is one question: What happens
>> if the timer has expired and someone tries to press the launch
>> button? I guess we do not want to allow that someone uses a launch
>> button which has already expired. To do this cleanly, we probably
>> need to add an 'expired(3)' status to the smLaunchOperStatus
>> object...

Eamonn> My thinking was that when the expiry time was reached the
Eamonn> smLaunchTable entry would simply disappear without trace.  So
Eamonn> if you try to push the button, you'll get an error because
Eamonn> it's no longer there.

Well, I am talking about the case where the timer has expired and
there are still entries in the smRunTable that were launched from the
smLaunchTable entry. In this case, I think the smLaunchTable entry
should stay around until the smRunTable entries are gone. This is
where I would change the smLaunchOperStatus to 'expired' in order to
inhibit any futher uses of the entry. (Its like a zombie in Unix
waiting for it's children to go away.)

/js

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 31 Jan 2001 18:15:50 +0100

Juergen Schoenwaelder wrote:
 [...]
> waiting for it's children to go away.)

I like the idea of the 'expired' status, but I do not like a timer
as a solution for running scripts 'in the background'. If you want to
run a script in the background you want the launch entry to expire
immediately after you lauched the script, which is hard to specify
as a timer value. Here, the 'onetime' status would be more desirable
switching to 'expired' immediately after the first launch.

    Juergen

---

From: Éamonn McManus <[email-masked]>
Date: Wed, 31 Jan 2001 18:36:38 +0100

> switching to 'expired' immediately after the first launch.

As I mention, this leaves the problem where the creator of the button
dies (or loses contact) before pushing the button.  I do not think it is
possible to create an smLaunchTable entry and launch it in a single SNMP
request.

My conception of a onetime button is that it really is used exactly
once, by the entity that created it.  So it is not particularly worrying
if the smLaunchTable entry hangs around longer than strictly necessary,
since nobody cares about it.  Additionally, the creator can get onetime
semantics by setting the expiry time to 0 at the same time as pushing
the button.  (This would need to be carefully specified.)

Éamonn