July 22, 201015 yr Ideally the events would still be triggered by any means of shutting down (command line admin, power button, UPS), not only by the Web GUI of emHttp. I would have the trigger inside of rc.local_shutdown to trigger the events in the shutdown.d directory and not rely on emHttp.
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? At that point I would consider the tense added to the event. We have a strong case to present for a start and stop event. If this is going to be put into emhttp, we should build a case for the started and stopped events. We can enhance the rc.event script to log via syslog when it begins and ends. Do we need emhttp to do these things? I'm not saying no to this. It has merit, I think with the workload, it needs to be presented in it's use to justify the added effort. The minimum we require is start/stop events. unRAID cannot grow well without these events. The others after that are gravy. Hash it out, that's what we're here for. I'm listening. and interested. sell it to me. LOL!!!
July 22, 201015 yr 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. I vote for running them, not describing them. Describe the situation in syslog and any event script can access what is needed. Since we will have a package mananger, now a front end for configuring packages or conf files or what is needed. notification tools will be layered on over time. I would like emhttp to notify us of events, but right now, I'm not sure that's the job of it. nagios could handle this, It can be set up to run scripts on events. These events are based on a resource and it is OK, WARNING, CRITICAL ACKNOWLEDGED and RECOVERED.
July 22, 201015 yr /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/ Agreed.
July 22, 201015 yr Author The minimum we require is start/stop events. unRAID cannot grow well without these events. The others after that are gravy. [CHECK] We can enhance the rc.event script to log via syslog when it begins and ends. Do we need emhttp to do these things? No. And we also don't need emhttp to worry about suspending callouts if in safe mode. We can put that logic in the master event script. OP updated, and I sent a PM to Tom to check the OP.
July 22, 201015 yr Well done. For the other events we can keep discussing them. Once we show the community needs, we can present it.
July 22, 201015 yr Author This can also simplify package initialization by the PM. Do we want to leave it to devs to handle scripts and symlinks for events in their .tgz, so installpkg puts them in the defined event.d directories? Or do we want to go with the .ini file parsing by the PM upon bootup, and have the PM handle populating the defined event.d directories?
July 22, 201015 yr 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. That's Horse??it. There is already confusion. This is how bad coding standards are designed in. I recommend: Array.Starting Array.Started Array.Stopping Array.Stopped Tom's events are not telling us to *start* our code. His events are telling us what his code is doing. We decide when to start our code. We decide based on the status of the array disposition. Your totally confusing what the event is all about.
July 22, 201015 yr This can also simplify package initialization by the PM. Do we want to leave it to devs to handle scripts and symlinks for events in their .tgz, so installpkg puts them in the defined event.d directories? This option is always available and it's probably the proper way, but I also think newer linux developers may need help. Or do we want to go with the .ini file parsing by the PM upon bootup, and have the PM handle populating the defined event.d directories? If someone wants to use advanced features of the package description then we can use it. If the Pman has an .ini, installs the package and the definitions exist, we should use it.
July 22, 201015 yr Author queeg, can you explain why this is not true: Array.Starting <-- useless event... nothing would ever be done here Array.Started Array.Stopping Array.Stopped <-- useless event... nothing would ever be done here
July 22, 201015 yr queeg, can you explain why this is not true: Array.Starting <-- useless event... nothing would ever be done here Array.Started Array.Stopping Array.Stopped <-- useless event... nothing would ever be done here Do you need to have it justified to you?? Does Tom know when the user has pressed the Start button? If so then the Array.Starting event is very simple to implement. Does Tom know when the array has stopped? If so then the Array.Stopped event is very simple to implement. Are you saying that if you can't use it then you don't want it? What's the big deal here? Is this a control issue?
July 22, 201015 yr 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. That's Horse?. There is already confusion. This is how bad coding standards are designed in. I recommend: Array.Starting Array.Started Array.Stopping Array.Stopped If you watch the emhttp on START and STOP you will see messages pop across the screen array_start() samba_start() These look like C function calls. I only mentioned it so there was continuity from emhttp. as far as Starting/Started. Stopping/Stopped. The case needs to be presented to show how it is going to be used with examples. I still do not see the need to run scripts on "Starting" When Is starting? When I click the button and I may be delayed mounting or expanding a drive. What would I run there or can I just wait for started (array is online at this point). I'm sorry, but I think it's more confusing with two start style events and two stop style events.
July 22, 201015 yr 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. That's Horse?. There is already confusion. This is how bad coding standards are designed in. I recommend: Array.Starting Array.Started Array.Stopping Array.Stopped If you watch the emhttp on START and STOP you will see messages pop across the screen array_start() samba_start() These look like C function calls. I only mentioned it so there was continuity from emhttp. as far as Starting/Started. Stopping/Stopped. The case needs to be presented to show how it is going to be used with examples. I still do not see the need to run scripts on "Starting" When Is starting? When I click the button and I may be delayed mounting or expanding a drive. What would I run there or can I just wait for started (array is online at this point). I'm sorry, but I think it's more confusing with two start style events and two stop style events. Yes, I understand that you don't get it. But my legitimate question is do you have to get it? Is it all about only you and Bubba here? If so then say so and I'll stand aside. I believe those events will have use. And I also believe it's quite simple to implement them.
July 22, 201015 yr Are you saying that if you can't use it then you don't want it? What's the big deal here? I can surely find something to fit in there. But do I really need to? What is my goal and first priority. Run scripts after the array is online. Run scripts before the array is taken offline. These are KEY factors for the next level of unRAID growth. If someone can present the case where the other events are really needed. with real world examples, then it carries enough weight to make the formal request. Have you looked at the OP?
July 22, 201015 yr Are you saying that if you can't use it then you don't want it? What's the big deal here? I can surely find something to fit in there. But do I really need to? What is my goal and first priority. Run scripts after the array is online. Run scripts before the array is taken offline. These are KEY factors for the next level of unRAID growth. If someone can present the case where the other events are really needed. with real world examples, then it carries enough weight to make the formal request. Have you looked at the OP? They will be simple to implement and difficult to request later. I'm assuming Tom will implement the event call as a function so adding another call to that function can't take as long as this discussion has taken.
July 22, 201015 yr Yes, I understand that you don't get it. But my legitimate question is do you have to get it? Is it all about only you and Bubba here? If so then say so and I'll stand aside. I believe those events will have use. And I also believe it's quite simple to implement them. Prove it to limetech with a real case. Show limetech how they will have use. They are the ones who will be doing the work. I'll advocate the position if I agree and even if I do not agree, I'm not going to block the request. This is easy enough for us to handle that the scripted level. I think the time duration from starting to started will be short most of the time. What needs to run in that window?
July 22, 201015 yr Yes, I understand that you don't get it. But my legitimate question is do you have to get it? Is it all about only you and Bubba here? If so then say so and I'll stand aside. I believe those events will have use. And I also believe it's quite simple to implement them. Prove it to limetech with a real case. Show limetech how they will have use. They are the ones who will be doing the work. I'll advocate the position if I agree and even if I do not agree, I'm not going to block the request. This is easy enough for us to handle that the scripted level. I think the time duration from starting to started will be short most of the time. What needs to run in that window? How do you handle a non-existent event in a script?
July 22, 201015 yr They will be simple to implement and difficult to request later. I'm assuming Tom will implement the event call as a function so adding another call to that function can't take as long as this discussion has taken. Locating the proper point in code is going to take time, Then there's testing, Then there is future maintenance. Support your request with real world examples.
July 22, 201015 yr Author I look at it this way: There is only ONE place in the array start process that makes sense to have any type of script call: at the end of the array start process. There is nothing to be done at the beginning of the array start process. There is only ONE place in the array stop process that makes sense to have any type of script call: at the beginning of the array stop process. There is nothing to be done at the end of the array stop process. They will be simple to implement and difficult to request later. I'm assuming Tom will implement the event call as a function so adding another call to that function can't take as long as this discussion has taken. I don't like making assumptions about someone else's code. Let's get the feedback from Tom on the things in red in the OP and go from there.
July 22, 201015 yr They will be simple to implement and difficult to request later. I'm assuming Tom will implement the event call as a function so adding another call to that function can't take as long as this discussion has taken. Locating the proper point in code is going to take time, Then there's testing, Then there is future maintenance. Support your request with real world examples. 1. How do you handle a non-existent event in a script? Locating the proper point in code? Pressing the Start button isn't hard to find. Knowing when the array is fully stopped -- hard to find? Let Tom decide if they are hard to find. If your reason is that Tom can't fit it in then I'll live with that. But if it's because you have to personally have a reason to use these events (or to at least get the verb tense correct) then I see fault with that.
July 22, 201015 yr As I indicated before, I see a valid need for having at least the two events of 'stopping' and 'stopped'. It's quite easy to prevent an array from stopping successfully, simply cd /mnt/disk1, so it would be advisable to know when the array was successfully stopped. Since this is supposed to be event driven, why not flush out the desired events now? I'd rather not have to go through a conversion process in the future should the events be added or needed later. I say we prioritize them based on our perceived needs and let LimeTech put them in based on those priorities and ease of development time. In the mean time, some of the events (started and stopped) can be synthesized by a monitoring program. To not have our framework be able to handle them may be a bit short-sighted.
July 22, 201015 yr Ok, here's a off-the-cuff example. 1. I want to have an LED or display show when the array is online or offline. How will I know that. The user can start and stop many times inbetween booting. When the start event is triggered, the array is online. Now third party apps are started. You can add your notification message to the start.d directory as the last entry S99LCD_online When the stop event is triggered, the array is being taken down, It is now calling all third party participants to stop their applications. Add your notification to the stop.d directory as the last entry S99LCD_offline The user can start and stop many times in between booting. And each suite of event directories will be run for those events. boot is only done once. If I stop the array, all stop events occur. when I press start, all start events occur. When I press stop, all stop events occur. and so on and so forth. shut is only done once.
July 22, 201015 yr As I indicated before, I see a valid need for having at least the two events of 'stopping' and 'stopped'. It's quite easy to prevent an array from stopping successfully, simply cd /mnt/disk1, so it would be advisable to know when the array was successfully stopped. Since this is supposed to be event driven, why not flush out the desired events now? I'd rather not have to go through a conversion process in the future should the events be added or needed later. I say we prioritize them based on our perceived needs and let LimeTech put them in based on those priorities and ease of development time. In the mean time, some of the events (started and stopped) can be synthesized by a monitoring program. To not have our framework be able to handle them may be a bit short-sighted. Based on this we NEED Array.Started Array.Stopping Array.Stopped leaving Array.Starting which is probably the easiest to implement up in the air. Again!! Array.Starting Array.Started Array.Stopping Array.Stopped
July 22, 201015 yr In the mean time, some of the events (started and stopped) can be synthesized by a monitoring program. To not have our framework be able to handle them may be a bit short-sighted. The frame work could handle it. Add two new events in emhttp. Add two new directories. I never said no, I only asked to present it. The more we present in the initial request, the better chance we have at getting it implemented. I tell you this discussion started almost 3 years ago. It's taken a while to show that this is needed. It sounds like you want confirmation that the events have finished. That will be there within the logs. every shcmd has the line that is called and the exit code as it finishes. Let me think about this more, but every little bit of discussion and presentation helps.
July 22, 201015 yr Of course I would prioritize the events of 'stopped' as second to last, and 'starting' as last. However having a 'stopped' event causes ripples with the event directory hierarchy so as to not be confused with the stopping event.
Archived
This topic is now archived and is closed to further replies.