July 21, 201015 yr I will update this OP as the discussion progresses. As of 5.0-Beta2: Callout script: /usr/local/emhttp/emhttp_event 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. Discussion: Two additional events have been suggested for: - disk or array failure... basically any change of a disk from on_line to any other state. A package that does alerts will like this. - array start failure ... if emhttp tries to start the array and it fails or if it starts but is degraded .... think about booting with a bad drive (or bad configuration). After feedback from Tom, it has been suggested that two callouts be put in the worker threads that monitor the disks ever 10 seconds. - diskreaderror - diskwriteerror Since the threads poll the disk only once per 10 seconds, a burst of errors will be self throttling. Emhttp calls the master event script and waits... period. Leave it up to the scripts farther down the line to launch commands/scripts in the background or not. WeeboTech has developed a mechanism for using timeouts. Need to consider "safe mode" checks and effect on callouts. We might want to consider leaving the shutdown callout active even in safe mode. Rather than having emhttp suspend callouts in safe mode, we can put that logic in the master event script ourselves, so we still get logging of the event calls. Consider second parameter to the master event script for text of an error or message. The community code for the master event script will handle the logic for suspending further script calls if in safe mode.
July 21, 201015 yr - The Package Manager will hook into that script, with a call to an intelligent script that ships with the PM that traverses event directories we define. can you elaborate more on this point?
July 21, 201015 yr Author can you elaborate more on this point? Sure... I took it out! Too many other things might like to use the event directories and the traversal logic. So think instead of the PM adding the intelligence of traversing directories to the master event script, I think there should be a simple community package (put in /boot/extra) on which PM will have a dependency, that puts the traversal code in the master event script.
July 21, 201015 yr can you elaborate more on this point? Sure... I took it out! Too many other things might like to use the event directories and the traversal logic. So think instead of the PM adding the intelligence of traversing directories to the master event script, I think there should be a simple community package (put in /boot/extra) on which PM will have a dependency, that puts the traversal code in the master event script. Yes, Thank you, that was going to be my point.
July 21, 201015 yr - disk or array failure... basically any change of a disk from on_line to any other state. A package that does alerts will like this. - array start failure ... if emhttp tries to start the array and it fails or if it starts but is degraded .... think about booting with a bad drive (or bad configuration). During some dinner and dishwashing I gave this some thought. - array start failure I believe emhttp will know about this and would be able to call this event out. Subsequently, the array_start event could not and would not run. - disk or array failure... This one we may have some trouble with. The foundation for it could be set up. I do not see this as the expected solution right at the moment with emhttp. My point is, I do not believe emhttp monitors the array health in real time. I believe it see's conditions and presents them. yet, unless someone has updated the display, it will not know a problem or array change has occurred. Now once it notices, it can execute this event. But it may be a lengthy time to call this event. Correct me if I'm wrong here. This event may require a third party monitor app (I'm going to work on Nagios).
July 21, 201015 yr Author OK, so we need to ask Tom if emhttp knows when a disk failure occurs or if an array failure occurs. diskerror --> a disk went from online to some other status. arrayerror --> array either failed to start or went offline other than due to a stop command. I think a disk failure has to be know, because a disk fails upon a failed write, and the driver certainly knows about it, so I suspect emhttp does too. Where do you suggest the master event script be located... in the initramfs or on the flash?
July 21, 201015 yr I think the START event should be two events. One when the array is STARTING and one for when it is STARTED, or RUNNING or something. That allows things to be done before and after it's started.
July 22, 201015 yr Author I think the START event should be two events. One when the array is STARTING and one for when it is STARTED, or RUNNING or something. That allows things to be done before and after it's started. That's in there... the boot event is when emhttp loads and the array is is about to be started, and the start event is when the array startup has completed.
July 22, 201015 yr bubbaQ, yes boot is there. But I think what's being proposed makes a subtle difference if someone does a start/stop/start cycle. I'm not sure what would need to be run before each start. If it has 'starting' and 'started' events, there should also be 'stopping' and 'stopped' events.
July 22, 201015 yr Author I don't see the utility of it. Boot does all the prep work for anything that needs to be prepped at boot. Start means the array is finished starting, and anything that needs the array started can now run. Stop informs apps that they need to close files so the array can stop. What would you want to do after "stopping" rather than do before starting the stop? Then suppose you want to start the array back up. What would need to be done at this point that can not wait until the "start" event when the array is fully online?
July 22, 201015 yr I don't see the utility of it. Boot does all the prep work for anything that needs to be prepped at boot. Start means the array is finished starting, and anything that needs the array started can now run. Stop informs apps that they need to close files so the array can stop. What would you want to do after "stopping" rather than do before starting the stop? Then suppose you want to start the array back up. What would need to be done at this point that can not wait until the "start" event when the array is fully online? I've noticed that getting verb tenses correct is not natural to many people. How about Start.Begin Start.Done Stop.Begin Stop.Done You may not see the use of it but you are boxing in other developers by closing off these events. Btw, Start <> Started, it means begin, it means your going to do something, not that you have already done it. As in Start your engines, not started your engines. Using the wrong tense is confusing to everyone who follows and it's a very outdated mindset.
July 22, 201015 yr I don't see the utility of it. Boot does all the prep work for anything that needs to be prepped at boot. Start means the array is finished starting, and anything that needs the array started can now run. Stop informs apps that they need to close files so the array can stop. What would you want to do after "stopping" rather than do before starting the stop? Then suppose you want to start the array back up. What would need to be done at this point that can not wait until the "start" event when the array is fully online? I've noticed that getting verb tenses correct is not natural to many people. How about Start.Begin Start.Done Stop.Begin Stop.Done You may not see the use of it but you are boxing in other developers by closing off these events. Btw, Start <> Started, it means begin. As in Start your engines, not started your engines. I agree... Although I do not currently know of a need for some of the events you are mentioning, not having them if you do is a lot harder to deal with than not having anything to do in one. Joe L.
July 22, 201015 yr I don't see the utility of it. Stop informs apps that they need to close files so the array can stop. What would you want to do after "stopping" rather than do before starting the stop? I can see some value in 'stopping' and 'stopped' if for no other reason than diagnostics and server monitoring. This would especially be of value since unRAID may be stuck in a stopping attempt since something external has a lock on one of the drives. Try a "cd /mnt/disk1" and try stopping the array. Wouldn't you like to know when the array has actually stopped?
July 22, 201015 yr Nice for monitoring... yes. but I can't think of an activity right now, other than a status e-mail, that I'd initiate after the array is stopped (Stop.Done) This is not to say I am opposed to the Start.Begin and Stop.Done events... quite the opposite, I think developers will find a use for them. Joe L.
July 22, 201015 yr It's allot right now, consider KISS. There's still a whole management process that has to devised. In reality consider. 1. we have boot already via the go script. It's just not run by emhttp and not as nice as we want. 2. start, This is what we need from emhttp. array online and "ready" "started" 3. stop. This is what we need from emhttp, array wants to stop "stopping". 4. we have shut already via the /etc/rc.d/rc.local_shutdown it's just not as nice as we want. Please describe where the other states come in. starting. OK. emhttp is initializing and starting things up. Now what would you really want to run before the array is ready? stopped. OK. emhttp has called our stop script. Now the array stop has completed. What would you really want to run if the array is offline? Please elaborate with starting, started(done), Stopping, Stopped. What will be run at all of these phases that could not be done in the other phase. Please keep in mind, limetech has to program all these call outs. The only place I can see "starting" and started(done) & stopping, stopped(done) is if you are somehow monitoring the array to see that it started/stopped correctly. I don't want to overwhelm limetech right now. After starting to code up my "locate" plugin, I can understand what was said when "tedious" was used.
July 22, 201015 yr Where do you suggest the master event script be located... in the initramfs or on the flash? initramfs. I would probably suggest that limetech installs the most basic one which just writes a message to syslog via logger. We will create a more advanced package to expand on it. If limetech adopts it as part of the system, that's a bonus. I would like the hooks without being a burden to limetech. Comments welcome.
July 22, 201015 yr Author I don't want to overwhelm limetech right now. Agreed... 110%. I would like the hooks without being a burden to limetech. Ditto. initramfs. I would probably suggest that limetech installs the most basic one which just writes a message to syslog via logger. We will create a more advanced package to expand on it. Agree completely. So we can live with just stop and start.... but we REALLY need those 2. If not too much trouble for Tom, the boot and shutdown would be nice, but not mandatory, and DO NOT DELAY next version of unRAID waiting for them If not too much trouble for Tom, the diskerror and arrayerror would be nice, but not mandatory, and DO NOT DELAY next version of unRAID waiting for them Suggestion for the place in initramfs for the master event script?
July 22, 201015 yr Author Rather than having emhttp suspend callouts in safe mode, we can put that logic in the master event script ourselves, so we still get logging of the event calls. Perhaps something like /etc/rc.d/unraid.d/ ? How about: /etc/rc.d/unraid.d/emhttp_event And the event directories: /usr/libexec/emhttp_event/boot/ /usr/libexec/emhttp_event/stop/ /usr/libexec/emhttp_event/start/ /usr/libexec/emhttp_event/shutdown/ /usr/libexec/emhttp_event/diskerror/ /usr/libexec/emhttp_event/arrayerror/
July 22, 201015 yr I would prefer it being in etc as close to the standard system admin functionality as possible. /etc/rc.d/event.d Yet I can see that getting unwieldy too. Is there a reason to put it in /usr/libexec (maybe I''m just not knowledgeable in that respect). My election would be. /usr/libexec/emhttp/event.d/rc (main script) /usr/libexec/emhttp/event.d/init.d /usr/libexec/emhttp/event.d/boot.d /usr/libexec/emhttp/event.d/start.d /usr/libexec/emhttp/event.d/stop.d /usr/libexec/emhttp/event.d/shut.d As for disk error, array error, I would like to keep it short, but I'm not going to press the issue. It may be worthwhile for limetech's input. If these matched emhttp subroutines It might be better.
July 22, 201015 yr Author I would prefer it being in etc as close to the standard system admin functionality as possible. /etc/rc.d/event.d That's fine, I was not married to libexec, but I'd like emhttp to be in the hierarchy: /etc/rc.d/rc.emhttp (main script) /etc/rc.d/emhttp/boot.d/ /etc/rc.d/emhttp/start.d/ /etc/rc.d/emhttp/stop.d/ /etc/rc.d/emhttp/shutdown.d/ /etc/rc.d/emhttp/diskerror.d/ /etc/rc.d/emhttp/arrayerror.d/ I was thinking, however, ... is there something that might traverse rc.d and descend into subdirs? Perhaps the toplevel should be: /etc/emhttp/start.d/ ... etc... Such as /etc/udev/rules.d Even if we don't get emhttp hooks for all the events now, Tom might add them in the future, and for the time being, I'm sure someone will ding up a monitoring package that will poll drive statuses every 5 minutes or so and allow us to trigger diskerror and arrayerror events. It may be worthwhile for limetech's input. I agree. Once we nail down the name of the path/filename for the master event script, I'll put it in the OP and ask Tom to review the thread.
July 22, 201015 yr /etc/rc.d/rc.emhttp (main script) [CHECK] /etc/rc.d/emhttp/boot.d/ /etc/rc.d/emhttp/start.d/ /etc/rc.d/emhttp/stop.d/ /etc/rc.d/emhttp/shutdown.d/ /etc/rc.d/emhttp/diskerror.d/ /etc/rc.d/emhttp/arrayerror.d/ I'm OK with this although I would have called it event.d rather then application specific. Some of these events may occur outside of emhttp. >> I was thinking, however, ... is there something that might traverse rc.d and descend into subdirs? Not intentionally. I've yet to see it occur and cause problems. In any case I'm open. Perhaps the toplevel should be: /etc/emhttp/start.d/ ... etc... I'm OK with this too. /etc/(application specific)/event specific. I can live with it.
July 22, 201015 yr So we can live with just stop and start.... but we REALLY need those 2. To minimize confusion, instead of START and STOP, call these events STARTED and STOPPING. start means, I am calling you to start your programs. start up your mysql daemon. start up your xmlrpc enabled web server. start up your rtorrent server stop means, I am calling you to stop your programs. stop mysql daemon. stop xmlrpc enabled web server. stop rtorrent server This "tense" of started, stopping. is not really needed when you understand when the events are called. end of array_start(), beginning of array_stop(). If there is confusion. we'll document the directory with a README. Think of it in terms of the start/stop buttons on the emhttp screens.
July 22, 201015 yr While I can agree with the explanations of the events and names, what would you suggest to use for a 'stopped event' should someone ding up a monitoring program and want to trigger events after its successfully stopped?
July 22, 201015 yr Author So.... /etc/rc.d/rc.emhttp (master event script) /etc/emhttp/boot.d/ /etc/emhttp/start.d/ /etc/emhttp/stop.d/ /etc/emhttp/shutdown.d/ /etc/emhttp/diskerror.d/ /etc/emhttp/arrayerror.d/ Since emhttp is the array management package, all the array events make sense to be under emhttp. The only ones that are possible outside of it are boot and shutdown, and shutdown is triggered by the shutdown button in emhttp, and boot is from the initialization of emhttp... so I think the emhttp hierarchy is appropriate. No one is forced to use them for boot or shutdown... any dev can instead hook into rc.local or rc.local_shutdown if they want. I also suggest a second parameter to the master event script... particularly useful for arrayerror and diskerror... to contain some info about the error, such as text. Particularly useful if a monitoring package for sending e-mail or text messages is installed.
Archived
This topic is now archived and is closed to further replies.