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

Then I would not suggest "sourcing"

 

You've already described a minimum run time of exclusivity, before the next "event" script is run, and a maximum run time before a script is terminated.

 

What else would be useful?  If just those two, then embedding them in the file name works.  If you expect the number to grow, that becomes unwieldy.

I have mixed feelings about the .conf file.  I'd actually prefer the embedded "#define MIN_EXCLUSIVE_TIME" and "#define MAX_RUN_TIME" lines at the top of an "event" "rc" file.  Easy to see all in one spot with the script involved, but it means editing the "rc" script to change. But.. I don't expect many people editing these.  On the other hand a parallel .conf file is very nice also easy to edit, and  less of an issue if mis-managed.  Easy for a package manager to add or delete as needed for special timings.

 

 

 

The #define directive works, but now we would have to parse it out of the file.

I'm going to admin I'm lazy.

 

redhat/centos uses config files for rc/init.d scripts through use of the /etc/sysconfig directory.

 

They source the file and continue.

 

The webGui front end can do a parse_ini.

Present options to change

write new .conf file and be done.

 

The shell can read and source the file directly.

 

If we use the #define directive, we have to sed the script to change it.

We also have to write some form of shell routines to grab these values.

 

The .conf file is optional and if we set reasonable values for the whole event process, then it probably will not be needed.

 

If we build a webGui set of routines to read .conf files, present them and update them, then the routines can be borrowed for other webGui plugins.

 

I don't see these timeout's values being something that people will use that often.

 

 

What was the result of those discussions with counsel?

 

Yes, let's not get bogged down on stuff that will rarely be used.

 

I like the .conf as it is a bit cleaner, and more self-explanatory.  It allows changing of a .conf w/o risking hosing the script, and vice versa.

 

Modding a .conf programatically is a lot easier than doing it to a script.

What was the result of those discussions with counsel?

 

Yes, let's not get bogged down on stuff that will rarely be used.

 

I like the .conf as it is a bit cleaner, and more self-explanatory.  It allows changing of a .conf w/o risking hosing the script, and vice versa.

 

Modding a .conf programatically is a lot easier than doing it to a script.

OK.

 

Since it is not an .ini file, is it OK to go with

#define MIN_EXCLUSIVE_TIME = 5

#define MAX_RUN_TIME = 60

 

Or do you have a different preference?

 

It is really easy to parse "#define" in a shell script.

 

rc=$script_name

min_exclusive_time=`grep "^#define MIN_EXCLUSIVE_TIME" "$rc" | sed 1q | tr -d " " | cut -d"=" -f2-`

max_run_time=`grep "^#define MAX_RUN_TIME" "$rc" | sed 1q | tr -d " " | cut -d"=" -f2-`

 

Joe L.

I suggest:

 

#define_unraid MIN_EXCLUSIVE_TIME =

 

just to make clear to anyone else that this is an unraid-specific line in the script.

I suggest:

 

#define_unraid MIN_EXCLUSIVE_TIME =

 

just to make clear to anyone else that this is an unraid-specific line in the script.

 

What does MIN_EXCLUSIVE_TIME mean?

I suggest:

 

#define_unraid MIN_EXCLUSIVE_TIME =

 

just to make clear to anyone else that this is an unraid-specific line in the script.

 

What does MIN_EXCLUSIVE_TIME mean?

A given "rc" script will be allowed to run in parallel with the next in the same event after this period of time.  The objective is to keep from running all in sequence which would slow down everything, or all in parallel, possible running into deadlocks/resource contention.

 

A default of a few seconds of (mostly) exclusive time will make a orderly start possible.  The event scripts will progress as fast as they can be invoked and completed, so it only affect those running more than the min-exclusive_time, but less than the max_run_time.

 

Perhaps I mis-understood the earlier posting.  What did -t XX -T YY represent?

 

Joe L.

I don't want to worry about parallel processing.

If need be, the event script can fork itself into the background.

 

the loggerexec program will have two timeouts.

 

1. -T number of seconds the executed command has to "COMPLETE" before it is forcefully killed. This can be a really large number.

 

2. -t number of seconds the logger exec will wait for some kind of input (from the command's stdout and/or stderr)  every time the child program writes something, this timer is reset. So if if loggerexec stops receiving input for some arbitrary number of seconds, it will assume something went wrong with the command and it is hung.

 

If the child provides stdout updates resetting the -t seconds value, then the -T seconds value kicks in as that is a master timer which says if the program does not end in this time period, make it end!

 

Neither of these is mandatory in the program itself.

We can add default mandatory values in the rc script.

 

 

I don't want to get into parallel processing of events at this point in time.

To do that you have to have a master program fork children and keep an internal table of the children.  Then update the table as each child finishes. Keep timers and control things in a managerial role.

 

At this point. I would like to have an event triggered by emhttp.

This calls a script, which runs each respective script in an event directory.

As protection, a tool will be build to insure that each respective script finishes in a reasonable time frame.

 

What you are suggesting in regards to parallel processing could have been handled in the "register to an event" model that Tom suggested a while back.  Before we go down that path, let's keep it as simple as possible with good documentation and a standard model to go by.

Do we have a prototype of the /etc/rc.d/rc.emhttp script for Tom?

 

Let's go simple for starters... no timeouts... just log the event and traverse the directories calling the +x scripts for now.

I'm working on something, but it's not quite the rc.emhttp.

I started working on something called rc.event to prototype with. I hooked it into the rc.local and rc.local_shutdown scripts.

I'm having issues with hooking it into rc.local right now. I have a package that updates rc.local from /boot/extra.

But since rc.local is what is loading boot/extra, it never picks up the added line to run rc.event.

My next step is to update the go script automatically from the /boot/extra.

 

Then package it up for a review.

Meanwhile I've merged some code from redhat's initlog into util-linux-ng logger.c and have to test it out.

I'm not touching rc.emhttp yet.

I started to, but then decided on a more generic event layout to replate the whole power-control/powerdown package then see how it works out.

 

Once that is done borrowing the framework and renaming things for rc.emhttp should provide a fast path.

Here's the events currently listed in the 5.0 beta 2, taken directly from /usr/local/emhttp/emhttp_event:

 

driver_loaded

#  Occurs early in emhttp initialization.

#  Can also occur as a result of init-config and device slot change.

#  Status information is valid.

 

array_started

#  Occurs during cmdStart execution.

#  The 'md' devices are valid.

 

disks_mounted

#  Occurs during cmdStart execution.

#  The disks and user shares (if enabled) are mounted.

 

svcs_started

#  Occurs during cmdStart execution.

#  The network services (samba, nfs, etc.) are started.

 

started

#  Signals end of cmdStart execution.

 

svcs_restarted

#  Occurs as a result of changing/adding/deleting a share.

#  The network services are started and may be exporting different share(s).

 

stopping_svcs

#  Occurs during cmdStop exeuction.

#  Nothing has actually been stopped yet, about to stop network services.

 

unmounting_disks

#  Occurs during cmdStop execution.

#  The network services have been stopped, about to unmount the disks.

 

stopping_array

#  Occurs during cmdStop exection.

#  The disks have been unmounted, about to stop the array.

 

stopped

#  Occurs at end of cmdStop execution.

#  The array has been stopped.

 

OP updated with release of -beta2

Have we actually developed the master event script (/usr/local/emhttp/emhttp_event) yet?  I'm ready to update my plugins to use it, but since there is no active code in the unRAID stock sript, I don't want to overwrite what it there, since I'm sure a future version will have it.

 

To start with, we could simply use:

 

find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} $1 $2  \;

 

 

Have we actually developed the master event script (/usr/local/emhttp/emhttp_event) yet?  I'm ready to update my plugins to use it, but since there is no active code in the unRAID stock sript, I don't want to overwrite what it there, since I'm sure a future version will have it.

 

To start with, we could simply use:

 

find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} 

\;

I've been working on one that implimented a lot of the ideas presented.

From my recollection, and based on this thread, and specifically, this post ,Tom was looking for the script names to be

event_<eventname>.sh

 

So, we would need to modify your simple line to be

find ./plugins -type f -perm/+x -maxdepth 2 -name event_${1}.sh -exec {} \;

 

Now, we could certainly experiment with both standards, and have two lines as follows:

find ./plugins -type f -perm /+x -maxdepth 2 -name event_${1}.sh -exec {} \;

find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} $1 \;

 

Note: I added $1 to the end of the exec on the line you suggested, since if only one script is involved, it would need to know the event being passed.

 

These would not be fool-proof, but it will get us running.   

 

For a start,we can put the two lines suggested above...and worry about synchronization when we get to a package that requires it.

 

We also have WeeboTech's suggestion for a central directory for those events that must be synchronized and his proposed

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

I think that depending on the naming used, the third approach suggesteg by WeeboTech might have an event called twice if it is linked to emhttp/event.d/.  We'll need to think that through based on Tom's post.

 

I've been working on a more fool-proof version, but wanted to wait to see what 5.2 offered first.  Never found the time to get it changed to use the scheme Tom implemented in 5.2.  I'll try to get to it later today.

 

Joe L.

Note: I added $1 to the end of the exec on the line you suggested, since if only one script is involved, it would need to know the event being passed.

 

I actually caught that omission and changed it before your post

 

After working with this a while, I really don't see a need to have multiple files, when the files are all native to one plugin.

Note: I added $1 to the end of the exec on the line you suggested, since if only one script is involved, it would need to know the event being passed.

 

I actually caught that omission and changed it before your post

 

After working with this a while, I really don't see a need to have multiple files, when the files are all native to one plugin.

I think the same way.  One script is sufficient.  (I've never needed to disable just one event, unless in development mode, and for that we can just edit plugin/event.sh )

 

So... one line is all we need for now to get everything started.

find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} $1 \;

 

Joe L.

Like        -> find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} $1 \;

Dont Like -> find ./plugins -type f -perm /+x -maxdepth 2 -name event_${1}.sh -exec {} \;

 

Teach the newbies to fish.

A good example.model to work with is worth the time and effort.

 

I would like to see this in addition.

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

This really comes in to play for scriptlets that are not gui oriented plugins.

 

 

 

Like         -> find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} $1 \;

So do I.

Dont Like -> find ./plugins -type f -perm /+x -maxdepth 2 -name event_${1}.sh -exec {} \;

Only reason I included it was because of Tom's post.  I prefer it all in one script with $1 to define the "event" occurring.

Teach the newbies to fish.

A good example.model to work with is worth the time and effort.

True.

I would like to see this in addition.

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

This really comes in to play for scriptlets that are not gui oriented plugins.

I agree.  It also has its place.

 

That gives us (to start)

find ./plugins -type f -perm /+x -maxdepth 2 -name event.sh -exec {} $1 \;

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

Joe L.

I would like to see this in addition.

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

This really comes in to play for scriptlets that are not gui oriented plugins.

 

I understand where you are coming from, but as I have aged () I think it it not a good fit for unRAID.

 

Tom has discussed the paradigm that unRAID be considered an Appliance.... and I think that is probably the best way for unRAID to be described.  We know it is a very "hackable" and extensible appliance, and that it is much more a hybryd than many other "appliances" out there.  But I think that paradigm is particularly well suited from the standpoint of widespread use and acceptance of unRAID to the general public, and success of unRAID is a positive for all of us that want to see its continued development -- particularly some major feature additions like q-parity and support for other array filesystems.

 

I am going to follow the idea that everything should be a plugin... even if it as fars as a user interface, it is nothing more than an icon and a single text page with the version and other "about" info.  A "scriptlet" should be a pluging... a super simple one for sure, but still a plugin.

I'm OK with it.

I can code the system to my liking.

 

I'm lazy, I have a whole directory of shells that do little things here and there.

I don't feel like writing plugin pages for everything.

 

I'll continue with the loggerexec. Now that I have my weekends back I can finish up.

 

The loggerexec is going to be a simple "drop in" to the find command line as in

 

-exec loggerexec {} $1

 

I can code the system to my liking.

 

If we couldn't .... would we have stuck around here this long? 

Perhaps one Gui-Plugin, with an "about" page, that in turn invokes its own

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

That way, it is a plugin, and it accommodates those of us that like have a collection of scripts that still need to be invoked upon startup/shutown

I do not see many of them going away.

 

I had mine in /boot/custom/etc/rc.d, you may have yours elsewhere.  (Interestingly, I no longer use any of these, having migrated them to .auto_install scripts)  Many do not warrant cluttering up the UI with a separate "About" page and icon.  They would only confuse the average user.  This will get easier when there is a package manager to enable/disable/install these scriptlets.

 

As an example, I have used at one time or another:

S01-initrc                  <- creates /root/.inputrc  to set editing mode

S10-install_custom_packages  <- this has since been replaced by the .auto_install scripts in unMENU

S120-apcupsd-package-install  <- now installed by a .auto_install

S124-smartctl                        - no longer needed, long since been a part of unRAID distribution

S20-spin_drives                      <- replaced by script run under control of unraid_addon_control.sh

S51-mail-forward-install          <- install /root/.forward file.  no longer needed with ssmtp mailer.

S03-timezone_copy                <- no longer needed now that time-zone install is fixed.

S10-smtp_alert                      <- no longer needed, replaced by unMENU .auto_install

S121-lsof-package-install        <- no longer needed, now part of unRAID distribution

S130-monthly_parity_check      <- no longer needed.  Now an unMENU package and installed with a .auto_install file.

S30-inittab-powerdown            <- installed with unMENU package and invoked with .auto_install file.

S70-update_nameserver          <- name-server now properly set. No longer needed.

S100-ntfs-3g-package-install  <- no longer needed, now an unMENU package.

S122-install-pciutils-package    <- no longer needed, now an unMENU package.

S40-set_read_buffer              <- no longer needed, unRAID sets buffers better.

S80-update_hosts                  <- no longer needed, unRAID sets localhost.

S10-fix_log_rotate                  <- no longer needed, log rotation now fixed in unRAID.

S110-file-package-install        <- now installed as an unMENU package.

S123-libraries-packages          <- missing libraries now include in unRAID

S150-spinup_when_accessed    <- now installed with a .auto_install script

S50-mail-install                      <- replaced with mailx/ssmtp installed by unMENU.

 

Perhaps one Gui-Plugin, with an "about" page, that in turn invokes its own

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

That way, it is a plugin, and it accommodates those of us that like have a collection of scripts that still need to be invoked upon startup/shutown

I do not see many of them going away.

 

I had mine in /boot/custom/etc/rc.d, you may have yours elsewhere.   (Interestingly, I no longer use any of these, having migrated them to .auto_install scripts)   Many do not warrant cluttering up the UI with a separate "About" page and icon.  They would only confuse the average user.   This will get easier when there is a package manager to enable/disable/install these scriptlets.

...

 

That is what I planned to do.

a gui plugin to build the event.d structure and add in the hooks.

 

I have a large directory of these fix it/install scripts too.

I know if I converted them to packages, I could do the fixit/installs in the install/doinst.sh script.

but that's a bit of work for all that I'm doing.

You don't want them all being individual plugins... packages either!

 

Collections of small scripts are naturally good candidates to be collected together into a single plugin, where the user can pick and chose which ones to enable/disable. 

You don't want them all being individual plugins... packages either!

 

Collections of small scripts are naturally good candidates to be collected together into a single plugin, where the user can pick and chose which ones to enable/disable. 

That is where a system "similar" to the user-scripts page in unMENU is handy.  A method to collect and impliment a series of tiny scripts and commands that have no need for anything but a button, or (now that we can) to be invoked on a specific event.

 

Joe L.