July 22, 201015 yr Yeah, think up and demand twelve more while you're at it, when we can't even get the two that are really needed. Now that would just be silly to demand events that can't possibly exist based on the state transition diagrams of the system.
July 22, 201015 yr Please get the verb tenses correct. If you have to provide a manual to explain what the name could explain then that's a waste of every coders time. Tom only types the names once. He won't care what the name is. Don't let this look like it was hacked together by a jr. coder. boot? booted I presume. shut? Shutting down I presume. Boot.Done Shuttingdown It's 2010 folks. Come on. Famous quote: We never have time to do it right but always have time to do it over.
July 22, 201015 yr 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/ I like this one, with a slight modification. The folks talking about tense are correct, at least IMHO (but i could honestly care less as I get what start and stop are doing) /etc/rc.d/rc.emhttp (master event script) /etc/emhttp/booting.d/ /etc/emhttp/started.d/ /etc/emhttp/stoping.d/ /etc/emhttp/stopped.d/ /etc/emhttp/shutdown.d/ /etc/emhttp/diskerror.d/ /etc/emhttp/arrayerror.d/ I think the tense makes it easier to understand. We need the events and probably need them implemented in this order (or close to it): started stopping shutdown boot diskerror arrayerror stopped
July 22, 201015 yr I would like emhttp to notify us of events, but right now, I'm not sure that's the job of it. emhttp must wait before it can cleanly stop the array (and, actually, it does today if the array has a disk that cannot be un-mounted) It will be up to the scripts we write to stop running processes. Once they do, the array will stop. There is no need for a "wait" directive to emhttp. It is implicit in the fact that a drive is busy. It will wait until it can un-mount all the drives. I did notice that the 5.0 release does have added messages written to the syslog when it is stopping and starting. They are probably the exact places the event call-outs are needed, so I would not worry too much about the work needed by Tom to impliment them in emhttp. I do see a need for some defined method to write text back to the unRAID iframe used to describe what is happening in the start up or shut down. It can be used to describe that a disk cannot be un-mounted because it is held busy by a telnet session, or whatever. Yes, we can log that information to the syslog, but it is so much better if presented to the user on the screen where they pressed the "Stop" button. This may be as simple as writing the informational message to a file that emhttp is monitoring and presenting to the user in the status iframe. Joe L.
July 22, 201015 yr Author I have posted feedback from Tom in the OP. Feedback from Tom: Here are the major transitions taken by emhttp: 1. Load the md/unraid driver (using modprobe). As a result of being installed, md driver establishes the 'disk status' and 'array status', though no md devices are yet exported. 2. 'Start' the md/unraid driver. Don't confuse with 'Array Start', where starting the md driver is the first step. Once the driver is started, the 'md' devices are available (and writes to an md device will also update parity). The process of Starting can also enable/disable disks depending on array status. 3. Mount the disks, including mounting the user share file system. 4. Start the network services, ie, Samba, NFS, AFP, etc. Stopping the array the steps go in the reverse order. During emhttp startup, it immediately executes step 1. Then when you click the 'Start' button, steps 2, 3, and 4 take place. It would be good to have a form of 'Start' that just executes step 2, because at end of step 2, the array is valid and this would be the time to execute a file system check.
July 22, 201015 yr Author I do see a need for some defined method to write text back to the unRAID iframe used to describe what is happening in the start up or shut down. It can be used to describe that a disk cannot be un-mounted because it is held busy by a telnet session, or whatever. So you want a way for a script or third-party applications to give a text string to emhttp, that emhttp would relay to the browser. The example is: - during the array stop procedure, the array stop callout results in a third-party program like SlimServer invoking its shutdown process - the SlimServer shutdown process may take some time, and it wants to inform the user that SlimServer is shuttig down... - so it wants to write "SlimServer is shutting down.... Please wait." in the emhttp UI. Another example: - during the array stop procedure, the array stop callout results in a third-party program that checks for open files. - the open file checker wants to write "A telnet session is open on /mnt/disk2 that is preventing array stop." I don't want to mess with files and locking and collisions.... I suggest a pseudofile like /proc/mdcmd
July 22, 201015 yr I do see a need for some defined method to write text back to the unRAID iframe used to describe what is happening in the start up or shut down. It can be used to describe that a disk cannot be un-mounted because it is held busy by a telnet session, or whatever. So you want a way for a script or third-party applications to give a text string to emhttp, that emhttp would relay to the browser. The example is: - during the array stop procedure, the array stop callout results in a third-party program like SlimServer invoking its shutdown process - the SlimServer shutdown process may take some time, and it wants to inform the user that SlimServer is shuttig down... - so it wants to write "SlimServer is shutting down.... Please wait." in the emhttp UI. Another example: - during the array stop procedure, the array stop callout results in a third-party program that checks for open files. - the open file checker wants to write "A telnet session is open on /mnt/disk2 that is preventing array stop." Exactly. An informed user is FAR better off, and we'll get far fewer forum posts about "I pressed 'Stop' and it just sits there" Or, I started the array, but my XYZ service did not start... If we had a method to write to the iframe, we could provide feedback that it had started, or not, and again the user is informed. I don't want to mess with files and locking and collisions.... I suggest a pseudofile like /proc/mdcmd Not sure a non-kernel process can use the /proc file-system, I do not think so... but we have many other possible interfaces. Easiest is just appending a file emhttp is reading, with no locking involved. (Much like the syslog) Just trying to keep it simple. Joe L.
July 22, 201015 yr Author An informed user is FAR better off, and we'll get far fewer forum posts about "I pressed 'Stop' and it just sits there" I agree, and I like the idea. Appending a file, means: emhttp has to constantly poll that file emhttp has to remember what in that file has already been sent to the user, and not send it again, but if the same message is written a second time, not suppress it as having already been sent. How about a socket connection like mySQL uses instead? (/tmp/mysql.sock)
July 22, 201015 yr An informed user is FAR better off, and we'll get far fewer forum posts about "I pressed 'Stop' and it just sits there" I agree, and I like the idea. Appending a file, means: emhttp has to constantly poll that file emhttp has to remember what in that file has already been sent to the user, and not send it again, but if the same message is written a second time, not suppress it as having already been sent. How about a socket connection like mySQL uses instead? (/tmp/mysql.sock) A socket, a named pipe, lots of possibilities (although some will block when full)
July 22, 201015 yr Author We should list the possible options, so they can be discussed and presented in a concise manner to Tom. - socket - named pipe IIRC, a named pipe has to be polled, but a socket can be assigned an event and generate that async event in the program.
July 22, 201015 yr An informed user is FAR better off, and we'll get far fewer forum posts about "I pressed 'Stop' and it just sits there" I agree, and I like the idea. Appending a file, means: emhttp has to constantly poll that file emhttp has to remember what in that file has already been sent to the user, and not send it again, but if the same message is written a second time, not suppress it as having already been sent. How about a socket connection like mySQL uses instead? (/tmp/mysql.sock) I think some form of socket should be used. We can write some tool like netprintf, etc, etc to write to the socket. If it were a UDP message then it would not matter if emhttp is up or not. Send a status message, emhttp captures it, stores it in a buffer, if the particular display has a place for this message, then display it. The other alternative is to just write a simple tool to use http posts to emhttp that update the message buffer display area. This might be the easiest way to do it emhttp can use sockets, pipes, shared memory, etc, etc. but it is a native network/embedded http server. I'm sure we can write a tool to do http (curl, php, etc, etc).
July 22, 201015 yr I noticed there is no php template for the main.page. I bet there is some window in there that gets updated and if we could write to it. We would be golden.
July 22, 201015 yr This might be an opportunity to add a new page for Events before hooking it into the Main events. We can then try things out with some button presses to see how it all works out.
July 22, 201015 yr More fuel for though root@unraidvm:/usr/local/webGui# cat Syslog.page Author="LimeTech" Version="1.0.0" Menu="Utils" Title="System Log" Type="/usr/local/webGui/scripts/pre cat /var/log/syslog"
July 22, 201015 yr I'm sure we can write a tool to do http (curl, php, etc, etc). No need to "write" a tool, "bash" can open and write to a network port as easily as echo "This is a status update message" > /dev/udp/localhost/12345 or echo "This is a status update message" > /dev/tcp/localhost/12345 All we need to do is agree on a port and protocol. It can read from a port too... Try this: cat </dev/tcp/time.nist.gov/13 Joe L.
July 22, 201015 yr I'm sure we can write a tool to do http (curl, php, etc, etc). No need to "write" a tool, "bash" can open and write to a network port as easily as echo "This is a status update message" > /dev/udp/localhost/12345 or echo "This is a status update message" > /dev/tcp/localhost/12345 All we need to do is agree on a port and protocol. It can read from a port too... Try this: cat </dev/tcp/time.nist.gov/13 Joe L. This requires limetech. A network socket, domain socket, fifo all require an open file descriptor and something added to a select loop based on that file descriptor. Then processing for that message. An http get will already be answered by emhttp fd select loop. I'm not much of a web developer, But what does this code do in /usr/local/webGui/style/template.php and can it be used? <iframe id="progressFrame" name="progressFrame" frameborder="0"></iframe> The bash udp/tcp way is very simple for us we need limetech's buy in to code it. (unless we can help ourselves).
July 22, 201015 yr Author When you create an iframe with an id, you can reference it in the DOM... it is an object in the memory of the browser. Depending on security constraints, you can write to the contents of the iframe with javascript in the browser. You can change the URL that is being displayed in the iframe. I suspect that the iframe is indeed displaying the contents of anther URL, and not being written to directly by the javascript since I'm not getting any security warnings and there are no certs being exchanged. So emhttp is simply writing output to an http connection.... nothing more.
July 22, 201015 yr Author After feedback from Tom suggesting the disk error callouts be generated in the worker threads, it was suggested that two callouts be put in the worker threads that are already monitoring the disks ever 10 seconds for activity. - diskreaderror - diskwriteerror Since the threads poll the disk only once per 10 seconds, a burst of errors will be self throttling and the callout only done once per 10 seconds for that disk.
July 24, 201015 yr Any more communication on this? Are we ready to start building the foundation, protocol, api? Or at least document it in the Wiki?
July 24, 201015 yr Author Just waitin on Tom.... We could go ahead and prototype the master event script for /etc/rc.d/rc.emhttp using /etc/emhttp/<eventname>/ I'd like it to be self-expandable, so it should be able to accept any new event names w/o recoding, so it should Parameter1 will be the event name. Additional parameters can be included, but are optional - Determine if there a dir named /etc/emhttp/<parameter1>.d/ - if so, execute all +x files in there with the parameters passed to me, shifted 1. so a call to: /etc/rc.d/rc.emhttp newEvent val1 val2 val3 will execute all the +x scripts in /etc/emhttp/newEvent.d/ and pass the parameter line "val1 val2 val3" to each one.
July 24, 201015 yr Author We should think about blocking and deadlocks. We don't want a hung event script to stop unRAID from shutting down, but then again, we don't want unRAID pulling the rug out from under an applications that needs to stop gracefully. Suggestions? I'm thinking the master script could check its process id, and fire off the subscripts async, and periodically check ps for child processes of itself.... and not return to unRAID until all the children have ended.... with a timout counter to do... something?
July 24, 201015 yr I'm thinking the master script could check its process id, and fire off the subscripts async, and periodically check ps for child processes of itself.... and not return to unRAID until all the children have ended.... with a timout counter to do... something? I don't want to overthink this. It may slow down prototyping. I agree with you 100% Let's get a model going along with hooks into unRAID. How does init handle this when you go into runlevel 6 or 0?
Archived
This topic is now archived and is closed to further replies.