I'm still "thinking out loud" on how we can manage system plugin start/stop.

 

Only 2 ways I really think are real candidates:

 

  - emhttp loads the plugins from the plugins root, and calls the script associated with each plugin when the trigger events happen.

 

or

 

  - when the trigger events happen, emhttp calls a single shell script, and that shell script that traverses the plugins and runs the script associated with each plugin.

 

I prefer the former, as it would be simple to implement since emhttp is already collecting and parsing the native plugins from /usr/local/webGui, and keeping all their parameters in the $pages array.  Simply duplicate that procedure for a $plugins array.

is it wrong for me to want both?

 

I see option 1 as important for the whole package/plugin manager approach.

 

I see option 2 for some of us who want to fend for themselves.

I.E. when the trigger events happen, emhttp calls a single shell script,  (STOP).

This is all I've ever been asking for in the past couple years.

 

For a complete package management approach, option 1.

 

For seasoned techs, option 2 and do not worry about me.

 

optionally with option 2,

Have WAIT/NOWAIT.

 

Run in background detached, not waiting for completion status.

Run in background waiting for completion status.

 

 

Example config.

 

/boot/config/events.cfg

bootexec=/boot/custom/etc/rc.d/rc.unRAID boot
bootwait=true
startexec=/boot/custom/etc/rc.d/rc.unRAID start
startwait=true
stopexec=/boot/custom/etc/rc.d/rc.unRAID stop
stopwait=true
shutdownexec=/boot/custom/etc/rc.d/rc.unRAID shutdown
shutdownwait=false

 

is it wrong for me to want both?

 

I see option 1 as important for the whole package/plugin manager approach.

 

Only if you want option 2 to call the plugin's scripts in addition to emhttp calling them.... that's overlap.

 

I think what you want is #1 to do the plugin scripts, and also have the #2 call made so non-plugin stuff can hook into events... but #2 should not also call the plugin scripts since #1 handles that.

Only if you want option 2 to call the plugin's scripts in addition to emhttp calling them.... that's overlap.

 

That's not what I want to do.

Some of this is basic adminstration/unix related. non gui plugin oriented work.

 

I think what you want is #1 to do the plugin scripts, and also have the #2 call made so non-plugin stuff can hook into events... but #2 should not also call the plugin scripts since #1 handles that.

 

Agreed. I would like to see this happen sooner then later.

Do we have any more comments on the events.cfg suggestion below.

We've talked allot about packages, management, configuration.

I would like to know if there are more suggestions here.

 

4 Events

 

/boot/config/events.cfg

 

# This script gets executed on first boot and start up of emhttp.

# it should run once per startup of emhttp.

# If execution needs to be prevented, use /var/lock/subsys/boot as a flag.

# example: restoring of /boot/etc configuration files might be done here

# or one of the subordinate calls

bootexec=path to script + args (boot).

bootwait=true or false

 

# This script gets executed AFTER the array is started and the environment has settled in.

# it can be run multiple times in a session.

# daemon initialization and startup occurs here.

startexec=path to script + args (start).

startwait=true or false

 

# This script gets executed BEFORE the array is stopped.

# killing of daemons and cleanup of anything "on the array" is done here.

stopexec=path to script + args (stop)

stopwait=true or false

 

# This script gets executed AFTER the array is stopped

# and the system is going into a power down state.

# caching etc configuration files to /boot/etc might be done here.

shutexec=path to script + args (shut)

shutwait=false or true

 

 

The wait true/false is if it's forked in the background or emhttp waits for the script to finish.

most of the shcmd's seem to be run while emhttp waits.

So this could be the default and leave out the wait= lines.

 

 

I did have one more suggested event, probably only useful to core system administrators.

I see where I could use this to initialize tmpfs areas I may need.

Patch some of the scripts which could use adjustment before being run.

There are actually a number of things done in rc.M which could probably be moved here.

or if need be patched out here.

I do not expect to see this get used to much.

I do see myself using it allot for advanced experiments.

It's just a hook.

 

# This script gets run by rc.M before going multiuser and before processing the /boot/extras.

initexec=path to script + args (init)

or

premexec, Pre Multiuser executeable.

 

Wouldn't it be easier to default to waiting, and if you don't want to wait, you put the & on the end of the command line?

 

However, I seem to recall a difficulty in the past launching background tasks from php called by a web server.... we might be back to traversing directories via script instead.

 

If scripts get hung or take a long time, we might also bump up against the php timeout.

I don't expect this to be called by php.

Think of the mover script and the "movenow" button.

 

Does that use php? Or does it use shcmd which is a fork/exec combo?

I would not expect these event scripts to be in php either.

Something underneath them, maybe, but they should be simple scripts to do rc.module work

I'm going to lock this topic... the thread on event handling has superseded it.

 

http://lime-technology.com/forum/index.php?topic=7101.0