How does init handle this when you go into runlevel 6 or 0?

 

It blocks AFAIK.

Can any plugins have dependencies on other plugins?  If so then the master shouldn't execute them asyncronously.

How does init handle this when you go into runlevel 6 or 0?

 

It blocks AFAIK.

 

I think it blocks for a period of time. Then starts killing stuff off forcefully.

I'm thinking run how the standard unix rc stuff runs, one at a time.

There should be a master process which fires off the child process, but makes an alert if something is hanging.  There should be a high timeout and if that occurs, handle it by killing the child process and moving on.

 

Normally I would say wait and just notify the admin, but in the case of a UPS shutdown, you have to do a best case solution and try and move on.

 

I'm thinking of writing a C program to fire off the child process.

If I set up two pipes between the parent and child. I can have the childs stdout/stderr redirected to the parent. Then use a select loop with a high time out.

Anything coming back on stdout fd will get written to syslog facility user.info

Anything coming back on stderr fd will get written to syslog facility user.err

Optionally also write to a log file.(doubt this is needed).

If nothing occurs within the timeout factor, the select loop will fall through and have to kill off the child.

I could make it advanced and fire off multiple processes, but I think I'm going to do it simple for now.

That could work.  But if you use something compiled and not a script to do the event handling, you loose configurability.  Or were you talking about a wrapper or helper to launch each script?

That could work.  But if you use something compiled and not a script to do the event handling, you loose configurability.  Or were you talking about a wrapper or helper to launch each script?

 

script to support the event subsystem, Compiled program to run the command redirecting stdout/stdout. Figure instead of running through logger it would run like.

 

 

loggerexec -- /etc/event.d/start/S01someprogram.

add some timeout condition

loggerexec -t90 -- /etc/event.d/start/S01someprogram.

 

the S01someprogram is unchanged, it writes to stdout/stderr.

Behind the scene loggerexec builds pipes to a child forks/execs the command line.

As the commandline writes,  all output is going into an embedded pipe.

 

if S01someprogram does not respond with at least 1 byte in the pipe for 90 seconds, the parent will be notified and kill the child.

 

Another choice is if S01someprogram does not "finish" in the timeout value, then kill the child.

These two values could be different.

 

loggerexec -t90 -T180 -- /etc/event.d/start/S01someprogram.

-t (any character resets this time)

-T (the script MUST complete in 180 seconds or it will be killed off).

 

I could add -s so output is put on stdout also or -o output is also written to a log.

 

 

It's just a different way of handling

/etc/event.d/start/S01someprogram | logger -is

 

The other choice is to make run a subshell in the background as.

( /etc/event.d/start/S01someprogram | logger -is ) &

then sleep or do a trap and then wait.

 

It's harder to do the proper thing in sh then C in this case.

 

The master rc script is still sh.

 

I do not plan to do the whole logger functionality, but if I get really motivated I will.

(Depends on how much coffee I drink.. but it's over 100 here.. so that may not work out!   )

I already have the framework in place for something we had to do on the mainframe.

 

I started to do a study today and brush up on my pipe knowledge.

That's what I meant by a helper program to launch the script. 

 

We're on the same page.

That's what I meant by a helper program to launch the script. 

 

We're on the same page.

 

Think RedHat's initlog, but with the RH specifics taken out and used in a manner like logger.

It only got to 99 here today.  But we went out dancing this evening... (think air-conditioning straining to get the temp down indoors)

 

I've got a good bit of what you are describing in the script I 've been using on my unRAId server for several months.

 

I'll modify it and publish it for comments and review.

 

It will allow each process an exclusive period of time (configurable) and then run the next in turn found in the rc.d (whatever directory we decide upon)

 

I'll modify it to pass additional arguments as suggested.

 

Joe L.

 

 

Can any plugins have dependencies on other plugins? 

 

Not for events, I would presume.

Can any plugins have dependencies on other plugins? 

 

Not for events, I would presume.

 

Events will be run in order of the filenames as they are installed in the directory.

Ascending Alpha/Numeric order. Same as with any other rc.d installation.

this is why they are usally named as

 

S01 through S99, so you can control the order.

 

Can any plugins have dependencies on other plugins? 

 

Not for events, I would presume.

 

With the Package Manager, any package can have installation dependencies, and the PM will take care of them.

 

If something has a dependency in its event script, the dev needs to write the script to do the checking and handle that dependency in the script itself.

loggerexec -t90 -T180 -- /etc/event.d/start/S01someprogram.

 

I want to make sure we are on the same page:

 

I envisioned /etc/rc.d/rc.emhttp as stock from unRAID, which

 

- logs the callout

- calls the scripts in the designated event directory.

 

What you propose above, is the unRAID stock /etc/rc.d/rc.emhttp, using the loggerexec, with parameters.  That is much more complex from the unRAID side.... or we have to go about modifying the stock unRAID script in the field.

 

Having had several years experience with sed scripts and the like modifying stock unRAID files, I want to kill that pig dead dead dead.

 

We need to put this intelligence in the scripts themselves.

 

I have some ideas (advanced scripts containing preloading logic and a recursive call to itself for example), but I have some other pressing stuff right now and don't have time to flesh them out.  So what are your ideas?

 

 

I have some ideas (advanced scripts containing preloading logic and a recursive call to itself for example), but I have some other pressing stuff right now and don't have time to flesh them out. So what are your ideas?

 

I would overwrite it, or if Tom makes it configurable as a "setting". We'll let the user update it.

 

If it's simple enough, only one line would need to change.

The line that is doing the actual run.

I will have a prototype this week.

I want to keep it as simple as possible.

 

if it's complex, then I'll have a plugin in the settings page that moves the production one out of the way and overlays the community one in place (and vica versa).

 

One of the beauties about the new emhttp plugin design, It can be an icon.

If it's simple enough, only one line would need to change.

 

Well.. not always.. .that is only if you intend one global timeout value for all scripts.  What if one script in /etc/rc.d/emhttp/stop.d needs a 3 minute timeout, and another need to be killed if it is not dead in 30 seconds?

 

The dev who authors a script should determine the timeout for THAT script... and if it the user needs to change the timeout, the dev needs to make that a configuration option in his plugin, that will modify THAT script... not modify the unRAID stock script.

if it's complex, then I'll have a plugin in the settings page that moves the production one out of the way and overlays the community one in place (and vica versa).

 

Hey everybody.  WeboTech just volunteered to write a really nice Event Manager plugin!!

 

 

If it's simple enough, only one line would need to change.

 

Well.. not always.. .that is only if you intend one global timeout value for all scripts.  What if one script in /etc/rc.d/emhttp/stop.d needs a 3 minute timeout, and another need to be killed if it is not dead in 30 seconds?

 

The dev who authors a script should determine the timeout for THAT script... and if it the user needs to change the timeout, the dev needs to make that a configuration option in his plugin, that will modify THAT script... not modify the unRAID stock script.

 

Good point.

 

if it's complex, then I'll have a plugin in the settings page that moves the production one out of the way and overlays the community one in place (and vica versa).

 

Hey everybody.  WeboTech just volunteered to write a really nice Event Manager plugin!!

 

LOL!!!!! I'm sure I will be involved!

You can call a script, that then calls itself.

 

The individual script called by the unRAID master event script can check if it was called with the "-reallydoit" flag set.

 

If not, it calls itself using loggerexec with a timeout, with all the same command line parameters it was invoked with from unRAID, but with the -reallydoit flag added,

 

When called with the "-reallydoit" flag set, then it proceeds normally.

 

This involves no change... or even knowledge... of unRAID.

 

While entirely possible, I'm not fond of that interface.

I have written scripts that if they are not run as root they will reexec themselves as root with

 

if (some test for root)

then echo -e "root \c"

      exec su root -c "$0 $@"

fi

 

I think it may be difficult to follow for newbies.

Even seasoned admins question me at times.

Let me think about this s'more.

There are other ways...

 

The master script can grep through the child script for some defined key that tells the master what timeout to use for it.... and use a default if there is no key:

 

#!/bin/bash

##UNRAID-SCRIPT-TIMEOUT=30

.

. rest of script

.

 

You can put the timeout in the script filename.  srriptme-script-T:30.sh 

 

 

Again, I'd like to avoid replacing or altering in the field, the stock unRAID master event script if at all possible.

 

 

I think it may be difficult to follow for newbies.

Even seasoned admins question me at times.

 

Cause you didn't use comments!

 

Seriously, one beef I have always had with clever programmers, is what they call elegant, I call a PITA to maintain.  Sometimes, yes, you can write one long command or hairy regexp that does what you want.

 

But from a code maintenance point of view, breaking it up onto 4 or 5 lines of code, with comments for each step, is more desirable (performance issues aside).

 

I think it may be difficult to follow for newbies.

Even seasoned admins question me at times.

 

Cause you didn't use comments!

 

Seriously, one beef I have always had with clever programmers, is what they call elegant, I call a PITA to maintain.  Sometimes, yes, you can write one long command or hairy regexp that does what you want.

 

But from a code maintenance point of view, breaking it up onto 4 or 5 lines of code, with comments for each step, is more desirable (performance issues aside).

 

Oh I agree about the long lines and hairy regexp!

 

It's interesting. I see us teetering between advanced unix scripting

i.e. reexecing oneself by checking command line arguments.

vs

Handling things and hiding stuff from a windows person.

In that respect. I would rather have a script installed and a .conf file that is sources before the script is called.

 

so if we have

script and script.conf

the master program sources script.conf then runs script, or the interface would to be the other way.

 

In either case, once we say, create/install a conf file to be sourced.

Then customizations can be programmed at the emhttp php level.

 

We still need to talk about services for these events. (in another thread).

 

emhttp -> events -> services

I can live with script and script.conf.

 

Lets limit the .conf to a small base of widely useful parameters, so we can get this framework to Tom and out the door.

 

Advanced .conf parameters can come with time, and be handled by that Event Manager Plugin that will replace the stock unRAID event manager script.

I can live with script and script.conf.

 

Lets limit the .conf to a small base of widely useful parameters, so we can get this framework to Tom and out the door.

 

Advanced .conf parameters can come with time, and be handled by that Event Manager Plugin that will replace the stock unRAID event manager script.

You really do not need to limit it.

 

You can easily code it like this:

 

script_configi=`basename $1`.conf

script_dir=`dirname $1`

[ -x "$script_dir"/"$script_config" ] && . "$script_dir"/"$script_config"

 

Any variables you like are now set in the environment by use of the "." (dot) operator. No need to "grep" for specific lines.

 

Granted there are potentials for abuse of the .conf file for any shell commands, but if you are able to write to these files or directories you have control of the server anyway.

 

Joe L.

 

When I said "limit" them, I mean limit the universe of options that the master event script would actually *do* something with.