May 18, 201016 yr Joe re-read Tom's section below The event lists are processed in order of registration, so a plugin can control desired order (at least statically). The order of plug-in registration can not currently be controlled, but I envision an "ordering" file available for download that would impose ordering (and dependencies) on plug-ins if necessary. This file would be maintained by the plug-in author community. So there could be a way of ordering. Would it be easy enough to do register ARRAY_START [slot] addon script register ARRAY_STOP [slot] addon script Instead of doing a First in First out, perhaps there could be a parameter where we put in a position number. If I choose position 0, it is just added to the stack at the current slot I've done this before with perl where I had to load information from config file. Variable[1]=value variable[2]=value and it would put it in that slot within the array. Any undefined slot value would default to 0. In my logic any duplicate number would stack it on that slot so Var[1]=Hi Var[1]=There Would resolve to Var[1] = "Hi","There"
May 18, 201016 yr As for some sorting order there, that's a "solution" to a problem that we don't have. Actually, it is exactly the problem we are trying to solve. [... ...] You seem to think that any add-on can be started or stopped in any order. Today, perhaps most can. But I can easily see where we would ... ... Again you are talking about future visions. Unriad 5.0 is good and all, but we are not in any rush to get it out. Whenever it happens it happens. In the mean time, if we are able to formulate our current problem in simple terms, and propose a simple enough solution to it, Tom may be inclined to grant us our wish in unRAID 4.5.5 or so. I think it highly unlikely that he would incorporate somebody's 200-line script in 4.5.5. For a nice and clean 10-line sctipt though he may give it a thought. So let me state our current problem as simply as possible, and you correct me if needed: ----- Many of our custom addons need to know when the array has fully started, so only then they can start doing their job. Many of our custom addons need to know when stop-array procedures have been initiated, so they can stop whatever they are doing and let the array stop cleanly. To accomplish that, we are currently polling the syslog, or polling '/proc/mdcmd', or what have you, and trying to make guesses as to whether the array has finally started, or whether a array-stop has been requested. Instead of polling and guessing, we would like to be notified of said events, so we can take the appropriate actions, if needed, to everybody's benefit. Such notifications can be accomplished by some "registration" mechanism, or simply by sitting with a script in a designated direstory. For example: /etc/array_events/ARRAY_START/my_script_that_cares /etc/array_events/ARRAY_START/joes_dir_caching_control /etc/array_events/ARRAY_START/weeboss_media_streamer_starter /etc/array_events/ARRAY_STOP/call_me_please /etc/array_events/ARRAY_STOP/me_too /etc/array_events/DISK_DSBL/my_custom_notifier I believe that it will be real easy for emhttp to notify all executable scripts that sit in directory '/etc/array_events/ARRAY_START/' after the array has fully started. Similarly, when the user presses the STOP button, emhttp can execute all scripts (if any) that sit in the '/etc/array_events/ARRAY_STOP/' directory. Alternatively, all such scripts can just sit in the same "events" directory, and emhttp can be calling them with passing them arguments like ARRAY_START, ARRAY_STOP, DISK_DSBL, etc. Scripts can act upon being passed arguments that they care about, and simply ignore arguments they don't care about. /etc/array_events/my_script_that_cares /etc/array_events/joes_dir_caching_control /etc/array_events/weeboss_media_streamer_starter /etc/array_events/call_me_please /etc/array_events/me_too /etc/array_events/my_custom_notifier Also, it would be nice if emhttp logs distinct entries in the syslog like "The array has started" and "Array-Stop has been requested", or some similar wording. ----- Would you say that the above summary correctly describes the current problem we are having? Would you say that the solution described would satisfactory address the problem? Is the above simple enough to be easily implementer in unRAID 4.5.x? How many of you would say "Tom, I would really like to have this soon, would you please give it a thought?"
May 18, 201016 yr Purko, I'm with you, but at a simpler level. let emhttp run one script at array start with the parameter start and run the same script before the array is stopped with the parameter stop. We can sweep the directory and execute the scripts in any manner we decide by modifying the script. We just need two hooks in emhttp as a call out for now. Since I don't know how far off unRAID 5.0 is, I'm also leary about asking for something that would delay 5.0 if it is close by.
May 18, 201016 yr Again you are talking about future visions. Have you read the post made by Tom @ lime-tech? It looks like you missed it. From what I've seen, there will be no hook to unRAID in the current 4.5 release. If he accommodates your request I'll eat my words. He is giving this thought, and seeing the flow of ideas. From what he just posted, we will not get triggers, it appears as if he will invoke our scripts. If you desire triggers, you'll need to write a script and register it with the appropriate events to generate them yourself. You seem to be all criticism. If you have a 10 line script to deal with all start and stop events, post it. I can almost guarantee it will not be in unRAID 4.5.5, but it might get you through your own needs. I know you can add a comment to your script, but that is already using 4 of your 10 lines. Perhaps you should re-think wasting those 4 lines on trivial comments intended to incite. Should we have a contest? Who can write the smallest script to perform the tasks we are describing? It would not be robust, but I'd love to see your entry to the contest. Joe L.
May 18, 201016 yr Purko, I'm with you, but at a simpler level. let emhttp run one script at array start with the parameter start and run the same script before the array is stopped with the parameter stop. Exactly what I said two posts ago. We could register a single plug-in [ script ] that in turn deals with all the dependencies and ordering of the multiple tasks, or register the individual tasks [ in the unraid.d folder ]. We only need ONE script to be registered for "ARRAY_START" and "ARRAY_STOP". It can loop through everything else and be modified as needed.
May 18, 201016 yr Purko, I'm with you, but at a simpler level. let emhttp run one script at array start with the parameter start and run the same script before the array is stopped with the parameter stop. I wholeheartedly agree. That's exactly what we talked earlier. But then we started adding complications out of proportion. That's where my concerns came from, (and not by a desire to piss off Joe), if we complicate the request, there's no chance in hell we'll see this in 4.5.x. We can sweep the directory and execute the scripts in any manner we decide by modifying the script. We won't even need to modify the supplied script, as it will be doing just that -- sweep the directory and execute the scripts (if any). Since I don't know how far off unRAID 5.0 is, I'm also leary about asking for something that would delay 5.0 if it is close by. We don't know how close it is, and I don't even want to bother Tom by asking about it. Let him take his time. I won't be surprised even if we see unRAID 5.0-beta around Christmas. I have no problem with that. Then it can easily be three more months before we get to unRAID 5.0-final. That's a year from now. We could use a nice little "events" patch in the current version, if it will be easy enough to implement.
May 18, 201016 yr Should we have a contest? Who can write the smallest script to perform the tasks we are describing? It would not be robust, but I'd love to see your entry to the contest. Very well. Here it is: #!/bin/bash for event_listener in /etc/array_events/* ; do if [ -x $event_listener ] ; then $event_listener ${1} fi done That's the only thing emhttp needs to call. If these 6 lines can get in 4.5.x, I can die happy.
May 18, 201016 yr Mine is a tiny bit smaller. 62 characters, even though the path to the directory I'm scanning is longer. If I used the path you did, it would only be 58 characters. /etc/rc.d/unraid.d/rc.* = 23 characters vs /etc/array_events/* = 19 characters find /etc/rc.d/unraid.d/rc.* -type f -perm /u+x -exec '{}' $1\; Either of our two contest entries will work, but both will depend on all scripts exiting. Neither, in my opinion, is anything I'd put in place for general use. Joe L.
May 18, 201016 yr Mine is a tiny bit smaller. 62 characters, even though the path to the directory I'm scanning is longer. If I used the path you did, it would only be 58 characters. /etc/rc.d/unraid.d/rc.* = 23 characters vs /etc/array_events/* = 19 characters find /etc/rc.d/unraid.d/rc.* -type f -perm /u+x -exec '{}' $1\; Either of our two contest entries will work, but both will depend on all scripts exiting. Neither, in my opinion, is anything I'd put in place for general use. Joe L. The bug in your version is that it will not execute soft links. Here's a better version: find /etc/array_events/ -exec {} $1 2>/dev/null \; Execute permissions take care of themselves.
May 18, 201016 yr Either of our two contest entries will work, but both will depend on all scripts exiting. "Hey, I just installed Joe L.'s new custom addon, and now my array won't stop!! HELP!!!" Do you think that such comment can be directed to Limetech? No. Right? Then it's not its job to worry about the scripts exiting. Neither, in my opinion, is anything I'd put in place for general use. If it is put in place, it will be many times better than what we have now (which is nothing).
May 18, 201016 yr Probably will be a 4.5.5 to add a couple drivers and some misc fixes. I can also throw in a few script call-outs as well.
May 18, 201016 yr Probably will be a 4.5.5 to add a couple drivers and some misc fixes. I can also throw in a few script call-outs as well. YES YES YES.... That will make me a very happy camper Thank you so much!!!!!!!!!! Do you think it would be possible to add CDROM support into the kernel. There is interest in being able to read and write CD's on unRAID. We can add the support programs via packages, but the basic CDROM support in the kernel is needed first.
May 18, 201016 yr Probably will be a 4.5.5 to add a couple drivers and some misc fixes. I can also throw in a few script call-outs as well. YES! Thank you Tom so very much!
May 18, 201016 yr We can add the support programs via packages, but the basic CDROM support in the kernel is needed first. Here are places in linux kernel config ('make menuconfig') that refer to CDROM. Any idea how many of these options are required? Device Drivers ---> ATA/ATAPI/MFM/RLL support ---> Included IDE/ATAPI CDROM support Device Drivers ---> SCSI CDROM support Device Drivers ---> Block devices ---> Packet writing on CD/DVD media File systems ---> CD-ROM/DVD Filesystems ---> ISO 9660 CDROM file system support File systems ---> CD-ROM/DVD Filesystems ---> ISO 9660 CDROM file system support / Microsoft Joliet CDROM extensions File systems ---> CD-ROM/DVD Filesystems ---> UDF file system support
May 18, 201016 yr I would enable all 3 filesystems (that will also allow mounting of ISO images with those too), and the ATAPI driver. The SCSI driver is not needed. The block driver is for writing recordable optical media.... probably not needed for the typical user, but someone will probably want it.
May 18, 201016 yr I would enable all 3 filesystems (that will also allow mounting of ISO images with those too), and the ATAPI driver. The SCSI driver is not needed. The block driver is for writing recordable optical media.... probably not needed for the typical user, but someone will probably want it. I concur. I'm stoked and getting excited again. have I mentioned how happy I am about call-outs?? LOL!
May 18, 201016 yr The block driver is for writing recordable optical media.... probably not needed for the typical user, but someone will probably want it. I should add, I want it. I store many ISO images on my unRAID server. When I need to create a CD for an OS. I drop in a CD-RW or DVD-RW and use cdrecord to make the CD. I'm wondering if we need the SCSI CDROM and IDE-SCSI subsystem? Anyone got a lead on that? Burning iso's from unRAID will help me eliminate one of my itx machines that just sit there for burns. PS> I'll buy another license in the next couple weeks if this can be added.
May 18, 201016 yr There was one NAS "pizzabox perhaps" that had a nice feature. After boot, any CD inserted in the drive would be auto ripped to iso and made available for mounting as a share later. Could be interesting later on.
May 18, 201016 yr There was one NAS "pizzabox perhaps" that had a nice feature. After boot, any CD inserted in the drive would be auto ripped to iso and made available for mounting as a share later. Could be interesting later on. True, a nice plugin could do that. What I miss about my readyNAS was the front panel USB port. When you mount a camera, it would automatically copy it to a dated directory on a share. When you pressed a button on the front, it would run a user defined backup job that could be used to do backups to a key, USB, rsync, etc, etc. I'm sure one day we'll get unRAID to do some of these things. I was on my way home thinking of the possibilities once we can read and burn CD's.
May 18, 201016 yr Here are places in linux kernel config ('make menuconfig') that refer to CDROM. Any idea how many of these options are required? Device Drivers ---> ATA/ATAPI/MFM/RLL support ---> Included IDE/ATAPI CDROM support Device Drivers ---> SCSI CDROM support Device Drivers ---> Block devices ---> Packet writing on CD/DVD media File systems ---> CD-ROM/DVD Filesystems ---> ISO 9660 CDROM file system support File systems ---> CD-ROM/DVD Filesystems ---> ISO 9660 CDROM file system support / Microsoft Joliet CDROM extensions File systems ---> CD-ROM/DVD Filesystems ---> UDF file system support It's nice to have all 3 filesystems setup so one can burn and read various types of discs. As for the actual drivers, this all depends on which drivers are used, the old deprecated drivers or the current drivers. Slackware 13.1 no longer includes ANY of the "ATA/ATAPI/MFM/RLL support (DEPRECATED)" drivers in their kernals. All the same support is handled via the "SCSI device support" and "Serial ATA and Parallel ATA drivers". So I think the question becomes do you want to be backwards facing or forward facing? The current/forward looking path is to not include any of the DEPRECATED drivers. The kernel description of CONFIG_BLK_DEV_SR [ Device Drivers > SCSI device support > SCSI CDROM support ] says the following: If you want to use a CD or DVD drive attached to your computer by SCSI, FireWire, USB or ATAPI, say Y and read the SCSI-HOWTO and the CDROM-HOWTO at <http://www.tldp.org/docs.html#howto> Make sure to say Y or M to "ISO 9660 CD-ROM file system support". To compile this driver as a module, choose M here and read <file:Documentation/scsi/scsi.txt>. The module will be called sr_mod. Here is how my ATA CD-Rom handled the shows up in the Device inventory done by emhttp via Serial ATA and Parallel ATA drivers and SCSI device support: May 13 02:32:11 Reaver emhttp: pci-0000:03:00.0-scsi-0:0:0:0 host6 (sr0) no id
May 18, 201016 yr Thanks Brit, I'm in the middle of remodeling my computers and I did not have time to go through it like that. My desk is like a plate of spaghetti as I start to unravel and retire machines.
May 20, 201016 yr There was one NAS "pizzabox perhaps" that had a nice feature. After boot, any CD inserted in the drive would be auto ripped to iso and made available for mounting as a share later. Could be interesting later on. True, a nice plugin could do that. What I miss about my readyNAS was the front panel USB port. When you mount a camera, it would automatically copy it to a dated directory on a share. When you pressed a button on the front, it would run a user defined backup job that could be used to do backups to a key, USB, rsync, etc, etc. I'm sure one day we'll get unRAID to do some of these things. I was on my way home thinking of the possibilities once we can read and burn CD's. Part of that can be done with SNAP addon. The last code update exposed hotplug events it's possible to run any script you want when you plug in your usb camera. I have mine to automatically copy the pictures to a share directory. And I'm intending to have automatic ripping of DVD's supported at some point. http://lime-technology.com/forum/index.php?topic=5904.0
July 2, 201016 yr Probably will be a 4.5.5 to add a couple drivers and some misc fixes. I can also throw in a few script call-outs as well. Any update on this front?
July 2, 201016 yr This would be great. Like you I keep ISO's that I need to burn from time to time. It would be really nice not to have to involve a PC for such a straightforward function. The block driver is for writing recordable optical media.... probably not needed for the typical user, but someone will probably want it. I should add, I want it. I store many ISO images on my unRAID server. When I need to create a CD for an OS. I drop in a CD-RW or DVD-RW and use cdrecord to make the CD. I'm wondering if we need the SCSI CDROM and IDE-SCSI subsystem? Anyone got a lead on that? Burning iso's from unRAID will help me eliminate one of my itx machines that just sit there for burns. PS> I'll buy another license in the next couple weeks if this can be added.
Archived
This topic is now archived and is closed to further replies.