May 17, 201016 yr Rename 'Restore' button. Even you guys can't figure out the right wording for this - so I got rid of it entirely in 4.5.4, replacing with a command called 'initconfig'. In those rare instances where a user needs to do this operation, the instructions will be to type 'initconfig' at the console or telnet session. But unlike users, we use this button all the time as part of the procedure to prep a server for shipment. This is because servers are tested with drives & once ready to ship, we need to 'Restore' the configuration to it's initial state so that when the customer boots up, it doesn't show a bunch of wrong/missing disks. Probably in the future we can re-address this and perhaps make a plugin for 5.0 called 'Expert Operations' where some of these more esoteric functions can be gathered together. I use this button, too and I will not be upgrading to 4.5.4 due to it going missing. I think this action was impulsive and incorrect, and my argument follows. UnRAID is a server platform for users and power users alike, and being webGUI-based, it needs to have the 'powerful' options available in the GUI. I think it is imperative to ignore the "nanny" impulse in a system like UnRAID. It is akin to having a sports car with 600bhp, but having the computer control the output so that you could never spin the tires if you wanted to.... So, removing it would not have been my first choice. I would rather have seen it move to a separate page, or at least another place within the webGUI where it would not be taken lightly, but still be part of the GUI. The suggestion of "expert options" is a good one in this vein. And as for naming it something descriptive, you've just done it with the command line by calling it "initconfig". So why can a button not have two (or three) words on it to describe it better? Init Array Config is pretty short (considering) but also leaves little doubt as to what it's about. Just my $0.02.
May 17, 201016 yr We will all discuss what a "bare minimum" script must do.... and what is must NOT do. It should invoke all the rc.* scripts in /etc/rc.d/unraid.d It should only invoke valid /etc/rc.d/unraid.d/rc.* scripts. It should not prevent the server itself from either starting or stopping. It should not get hung up on any single rc.* script... In other words, it must always return, even if a rc.* script hangs waiting for an event that never occurs. Just to be pedantic... It should invoke all the executable rc.* scripts in /etc/rc.d/unraid.d/ directory. That way one can disable a script by removing the execute bit. This is the same way the /etc/rc.d/ system is handled.
May 17, 201016 yr We will all discuss what a "bare minimum" script must do.... and what is must NOT do. It should invoke all the rc.* scripts in /etc/rc.d/unraid.d [red]It should only invoke valid /etc/rc.d/unraid.d/rc.* scripts.[/red] It should not prevent the server itself from either starting or stopping. It should not get hung up on any single rc.* script... In other words, it must always return, even if a rc.* script hangs waiting for an event that never occurs. Did you have something special in mind when you said "valid" script? It may not even be a script, it can be binary. If (1) the name starts with 'rc.' and (2) its execute bit is set, then that's "valid".
May 17, 201016 yr We will all discuss what a "bare minimum" script must do.... and what is must NOT do. It should invoke all the rc.* scripts in /etc/rc.d/unraid.d It should only invoke valid /etc/rc.d/unraid.d/rc.* scripts. It should not prevent the server itself from either starting or stopping. It should not get hung up on any single rc.* script... In other words, it must always return, even if a rc.* script hangs waiting for an event that never occurs. Just to be pedantic... It should invoke all the executable rc.* scripts in /etc/rc.d/unraid.d/ directory. That way one can disable a script by removing the execute bit. This is the same way the /etc/rc.d/ system is handled. I did not specifically say that the rc.* had to be executable, but the code I attached has: # make sure the unraid.d script has the "start" or "stop" keyword somewhere in it. grep "\W*${1}\W" $rc_script >/dev/null 2>&1 if [ "$?" = "0" ] then if [ -x $rc_script ] <- If the script is executable then We are in agreement. The "stock (bare minimum)" script you initially described has to contain a fair amount to code to allow no mis-behaving add-on to prevent the start or stop of the array from completing AND allow management of the rc.* scripts as you described by changing their execute bit. As I said, I've been living with a version of the above script on my server for a while now, with MANY start and stops of the array... (I tend to do that a lot as I try things) Is my script the perfect one, or have everything we will need once unRAID 5.0 is released, I doubt it... but it is a starting point. Advanced developers, such as yourself, can get ideas from it and improve it, and as a team we can bounce ideas off each other. We may not ever agree on everything, but the best of the ideas will be discovered. Joe L.
May 17, 201016 yr We will all discuss what a "bare minimum" script must do.... and what is must NOT do. It should invoke all the rc.* scripts in /etc/rc.d/unraid.d [red]It should only invoke valid /etc/rc.d/unraid.d/rc.* scripts.[/red] It should not prevent the server itself from either starting or stopping. It should not get hung up on any single rc.* script... In other words, it must always return, even if a rc.* script hangs waiting for an event that never occurs. Did you have something special in mind when you said "valid" script? It may not even be a script, it can be binary. If (1) the name starts with 'rc.' and (2) its execute bit is set, then that's "valid". purko, Have you ever personally encountered an "rc.* script that was NOT a shell script? In 30 years of using unix/linux I have not. But, I imagine they could be written as a compiled program, I've just never seen any. However, I did not exclude binary rc.* scripts, and currently my script is looking, using "grep", for the word "start" or "stop" as appropriate in the script itself before executing it with that argument. "grep" will work on a binary or a shell script equally well since I am only interested in the exit status. I just did not want it to invoke a rc.* script with a command argument that it did not support. (That would only happen if the rc.* command was completely non-compliant with the standards we expect) Again, "bare-minimum" has a lot to do.. but we both still agree, some minimum amount of error checking is needed to keep a rc script from allowing the server to complete its start or stop operations. Joe L.
May 17, 201016 yr Rename 'Restore' button. Even you guys can't figure out the right wording for this - so I got rid of it entirely in 4.5.4, replacing with a command called 'initconfig'. In those rare instances where a user needs to do this operation, the instructions will be to type 'initconfig' at the console or telnet session. But unlike users, we use this button all the time as part of the procedure to prep a server for shipment. This is because servers are tested with drives & once ready to ship, we need to 'Restore' the configuration to it's initial state so that when the customer boots up, it doesn't show a bunch of wrong/missing disks. Probably in the future we can re-address this and perhaps make a plugin for 5.0 called 'Expert Operations' where some of these more esoteric functions can be gathered together. I use this button, too and I will not be upgrading to 4.5.4 due to it going missing. I think this action was impulsive and incorrect, and my argument follows. UnRAID is a server platform for users and power users alike, and being webGUI-based, it needs to have the 'powerful' options available in the GUI. I think it is imperative to ignore the "nanny" impulse in a system like UnRAID. It is akin to having a sports car with 600bhp, but having the computer control the output so that you could never spin the tires if you wanted to.... So, removing it would not have been my first choice. I would rather have seen it move to a separate page, or at least another place within the webGUI where it would not be taken lightly, but still be part of the GUI. The suggestion of "expert options" is a good one in this vein. And as for naming it something descriptive, you've just done it with the command line by calling it "initconfig". So why can a button not have two (or three) words on it to describe it better? Init Array Config is pretty short (considering) but also leaves little doubt as to what it's about. Just my $0.02. Lime-tech's action to remove the button labeled as "restore" from the web-interface was not 'impulsive and incorrect' but the result of over three years of feedback and lobbying by the user community. It was just too easy to make the wrong choice when managing your array, especially if English is not your native language. If you wish to press the "Restore" button from the web-interface, all you need to do is put the following URL in your browser's address bar after first stopping the array. \\tower\blank.htm?cmdInit=apply It is exactly the same as if you logged in to linux and used the command line, and is what the new initconfig command does behind the scene. The button labeled "restore" has caused data loss. I too would have been just as happy if it was just re-labeled and a better description added, but this way it is FAR less likely to cause a loss of data when a user thinks it is how to "restore" their data after a disk has failed and then install a replacement disk. A experienced user will know when to use the "command line version", and an inexperienced user will not press it at the wrong time. The performance improvements in 4.5.4 vastly outweigh the inconvenience of you needing to go to the command line to set up a new initial configuration. If you do not wish to upgrade, fine. Just be aware of the bugs in your existing version. (Every version prior to 4.5.4 can show disks as un-formatted when they are unable to be mounted. Every version prior will show the "Format" button when it thinks an unformatted drive is present. As long as you do NOT press the button when drives with data show as un-formatted, you'll be fine, just be extra careful) Joe L.
May 17, 201016 yr ...currently my script is looking, using "grep", for the word "start" or "stop" as appropriate in the script itself before executing it with that argument. That's the only piece I don't like much. Your script shouldn't be in the business of checking inside other scripts. Just execute the darn thing. You are going way out of your way to protect me from me. That's the microsoft way. I may want to put there a script which isn't interested in the arguments you pass to it. Why should you be stopping me from doing that? Should I have to have a commented line with your key words just to make it work? A "bare minimum" script that does the job is 10 lines tops. Remember, we are talking about user customizations here -- neither you nor Limetech are expected to give any warranties whatsoever. If I install a crappy customization that hangs the array stop, then be it. It's not your fault.
May 17, 201016 yr ...currently my script is looking, using "grep", for the word "start" or "stop" as appropriate in the script itself before executing it with that argument. That's the only piece I don't like much. Your script shouldn't be in the business of checking inside other scripts. Just execute the damn thing. You are going way out of your way to protect me from me. That's the microsoft way. I may want to put there a script which isn't interested in the arguments you pass to it. Why should you be stopping me from doing that? Should I have to have a commented line with your key words just to make it work? A "bare minimum" script that does the job is 10 lines tops. Remember, we are talking about user customizations here -- neither you nor Limetech are expected to give any warranties whatsoever. If I install a crappy customization that hangs the array stop, then be it. It's not your fault. Then you can remove that check. When I expect ALL scripts to properly use the "start" and "stop" keywords, I expect them to comply. You can put those two words in a comment in the "damn thing" so "grep" will find them but they'll have no impact. You can remove the check from YOUR copy of the rc.custom script. I've seen the attempts at scripting produced by in-experienced coders here, perhaps you are better than most of them... no way to know. I've seen your posts and you know far more about the administration of Linux than most, including myself, but I know nothing of your scripting abilities. They probably are equally advanced. You are correct, I'm trying to protect you, and everybody else from a script that ignores "stop" and instead tries something else that prevents the array from stopping. If you do not like the test, fine, point noted, but it is a valid point when you have absolutely NO control over what will end up in the unraid.d directory. Joe L.
May 17, 201016 yr I am inclined to agree with JoeL on this one. unRAID is meant to be as user friendly and minimalist as possible, but there is a point were the KISS approve just does not give the best results. "grep'ing" (my new word of the day) is a good way to insure a few of the conditions are met. There is a reason standards are set and if a "start" and "stop" function are set as required standards for a bare minimum i don't think that is to much. Another good example of this is the current powerdown shipped with stock unRAID. It is simple as can be, but that is a little bit of a detriment as far as i am concerned. It will just keep looping is a disk is busy and eventually hard lock the server resulting in an unclean powerdown. If a "--killall" option (or a tick box similar to the "sync disks" one) was added it would go a long way to getting the server shut down in a more clean manner.
May 17, 201016 yr I'm not fond of grep'ing the script to look for start/stop keywords. It might be easier to do it like SYSV and just have it named S## (for start and 2 digits for where in the list you want it to start) and K## (for stop and 2 digits for where in the list you want it to stop). This allows people to have individual starts/stops and even designate where in the process it occurs.
May 17, 201016 yr I'm not fond of grep'ing the script to look for start/stop keywords. It might be easier to do it like SYSV and just have it named S## (for start and 2 digits for where in the list you want it to start) and K## (for stop and 2 digits for where in the list you want it to stop). This allows people to have individual starts/stops and even designate where in the process it occurs. That can work as easily, and adds the ability to dictate start and stop order (by changing the numeric portion of the name) I can easily envision a case where a given add-on needs to be started last, and stopped first. The only complication is the need for two scripts instead of one. Perhaps upon installation, they can just be linked.... or would that be too confusing? Or ... should we accommodate both naming conventions? rc.* with embedded logic to use "start" and "stop" keywords, AND K* and S* scripts that implicitly know to start and stop? It is trivial to do both in the same rc.custom script, getting the best of both worlds. I prefer the rc.* convention only because I can add other key-words such as "status" or "restart" easily, and it keeps with the convention used in slackware's own /etc/rc.d. Other than that, I'm open to suggestions. I really think we do eventually need to be concerned with the order of add-on start and shutdown, but the problem is, we have no way of controlling OTHER K*/S* scripts added later and where they will fit into the numeric sequence. Are 2 digits enough for grouping and to leave "gaps" in the numbering to allow ease to fit in another task at a later date. Your thoughts? Joe L.
May 17, 201016 yr Another possibility to deciding the "order" of scripts is to require each "add-on" to add itself to a list of start-up and shut-down tasks. That could be as simple as two text files, with the rc.* scripts listed in the desired order, and use something like for script in `cat rc.start_order` and for script in `cat rc.stop_order` vs. for script in /etc/rc.d/unraid.d/rc.*
May 17, 201016 yr Or ... should we accommodate both naming conventions? rc.* with embedded logic to use "start" and "stop" keywords, AND K* and S* scripts that implicitly know to start and stop? It is trivial to do both in the same rc.custom script, getting the best of both worlds. As I'm thinking out loud here. I would prefer to deviate a bit from slackware considering the little bit of heat in this thread. It's easy enough to run the rc.* scripts. But I would prefer to filter them based on the K* and S*. This lets us add a level if we need to. As far as requiring two scripts. In SYSV, Usually the script is dropped in init.d and linked to the respective rc.# directory. We can use the same logic and drop scripts in /etc/init.d and link them with appropriate names in an rc.unraid directory. Having one script with the ability to do stop/start/restart/status is installed in /etc/init.d Having a link from /etc/init.d to /etc/rc.unraid or unraid.d whatever named according to convention insures something wont get run by accident. it does allow those who want to do things as simple as possible, the ability to just drop S## and K## scripts in the rc.unraid directory. I'm thinking out loud or "onscreen", please consider that before #!/bin/bash ing me. ;-)
May 17, 201016 yr Another possibility to deciding the "order" of scripts is to require each "add-on" to add itself to a list of start-up and shut-down tasks. That could be as simple as two text files, with the rc.* scripts listed in the desired order, and use something like for script in `cat rc.start_order` and for script in `cat rc.stop_order` vs. for script in /etc/rc.d/unraid.d/rc.* hmmm, I think this is more complex then it needs to be. ln -s /etc/init.d/scriptname /etc/rc.unraid/K##scriptname is easier to do. for script in /etc/rc.unraid/K* do $script (start or stop) done is very simple. or /etc/rc.d/unraid.d/K* I'm getting confused. i work on too many different platforms.. heh.
May 17, 201016 yr really think we do eventually need to be concerned with the order of add-on start and shutdown, but the problem is, we have no way of controlling OTHER K*/S* scripts added later and where they will fit into the numeric sequence. Are 2 digits enough for grouping and to leave "gaps" in the numbering to allow ease to fit in another task at a later date. 2 digits should be enough. I've seen some pretty big systems and with the tight community we have here this should be fine. an unmenu plugin can be devised to show people the order scripts would be run in and to easily disable them by removing the link or taking the x bit off.
May 17, 201016 yr Another possibility to deciding the "order" of scripts is to require each "add-on" to add itself to a list of start-up and shut-down tasks. That could be as simple as two text files, with the rc.* scripts listed in the desired order, and use something like for script in `cat rc.start_order` and for script in `cat rc.stop_order` vs. for script in /etc/rc.d/unraid.d/rc.* hmmm, I think this is more complex then it needs to be. ln -s /etc/init.d/scriptname /etc/rc.unraid/K##scriptname is easier to do. for script in /etc/rc.unraid/K* do $script (start or stop) done is very simple. or /etc/rc.d/unraid.d/K* I'm getting confused. i work on too many different platforms.. heh. True, linking is simpler, but a text file with a series of lines is FAR easier to re-order to get the sequence as you like when all of a sudden a new rc.* script shows up that needs to be between two adjacent existing numbered scripts. Again, just discussing the pros and cons. I've been bashed before... and any reasonably valid argument will always win over any stupidity I might exhibit. I'm just envisioning an add-on screen to manage this at some point. A list of tasks stored someplace, somehow, is easier for many beginners who have no idea of the stuff we are talking about than re-numbering some or all the K*/S* tasks to accommodate a new one they want to add... Joe L.
May 17, 201016 yr I'm just envisioning an add-on screen to manage this at some point. A list of tasks stored someplace, somehow, is easier for many beginners who have no idea of the stuff we are talking about than re-numbering some or all the K*/S* tasks to accommodate a new one they want to add... I think this is something a user interface could do. Read /etc/init.d (or some directory or some file) Present it to the user. make the links according to a suggested numeric method. I think this goes to far beyond a simple approach to stop and start scripts. At least in the first go round. Redhat has the chkconfig tool which uses suggested keywords in the rc script to set the position. Example slimserver:# chkconfig: 345 80 30 smartd:# chkconfig: 2345 40 40 smb:# chkconfig: - 91 35 snmpd:# chkconfig: - 50 50 snmptrapd:# chkconfig: - 50 50 speechd:# chkconfig: 345 85 15 squid:# chkconfig: - 90 25 sshd:# chkconfig: 2345 55 25 sulogin:# chkconfig: syslog:# chkconfig: 2345 12 88 syslog-ng:# chkconfig: 2345 12 88 vmware:# chkconfig: 235 19 08 vncserver:# chkconfig: - 91 35 winbind:# chkconfig: - 91 35 xfs:# chkconfig: 2345 90 10 xinetd:# chkconfig: 345 56 50 I'm not fond of maintaining an external file to set run order. There shouldn't be that much interdependence.
May 17, 201016 yr I'm just envisioning an add-on screen to manage this at some point. A list of tasks stored someplace, somehow, is easier for many beginners who have no idea of the stuff we are talking about than re-numbering some or all the K*/S* tasks to accommodate a new one they want to add... I think this is something a user interface could do. Read /etc/init.d (or some directory or some file) Present it to the user. make the links according to a suggested numeric method. I think this goes to far beyond a simple approach to stop and start scripts. At least in the first go round. Redhat has the chkconfig tool which uses suggested keywords in the rc script to set the position. Example slimserver:# chkconfig: 345 80 30 smartd:# chkconfig: 2345 40 40 smb:# chkconfig: - 91 35 snmpd:# chkconfig: - 50 50 snmptrapd:# chkconfig: - 50 50 speechd:# chkconfig: 345 85 15 squid:# chkconfig: - 90 25 sshd:# chkconfig: 2345 55 25 sulogin:# chkconfig: syslog:# chkconfig: 2345 12 88 syslog-ng:# chkconfig: 2345 12 88 vmware:# chkconfig: 235 19 08 vncserver:# chkconfig: - 91 35 winbind:# chkconfig: - 91 35 xfs:# chkconfig: 2345 90 10 xinetd:# chkconfig: 345 56 50 I'm not fond of maintaining an external file to set run order. There shouldn't be that much interdependence. purko would prefer it to not look into his files to learn if they have a preference for being invoked in a given order, and it will probably be more than 10 lines of code. But it would work for me. I did not love a separate file either, but it was one way to specify order easily. As you said, we can develop a add-on screen to manage this once we know what it is we need to manage. As you said, the start stop order will have very few inter-dependencies. Joe L.
May 17, 201016 yr purko would prefer it to not look into his files to learn if they have a preference for being invoked in a given order, and it will probably be more than 10 lines of code. I would not do this at run time. This would be another tool which creates links. For now just installing the file in /etc/init.d or is it /etc/rc.d for slackware. Then linking to /etc/rc.d/unraid.d/K## or S## would suffice. This makes an /etc/rc.d/rc.unraid script very simple. start means run all S## scripts in /etc/rc.d/unraid.d with argument of start stop means run all K## scripts in /etc/rc.d/unraid.d with argument of stop
May 17, 201016 yr I reread the posts a few times, and I still can't see the benefit to having different "k" and "s" etc. scripts. Why don't we stick to the way Slackware does things? Even the simplest "rc.*" script can take parameters and act accordingly. As for some sorting order there, that's a "solution" to a problem that we don't have. By complicating things at this point we are only decreasing the chances of Limetech actually doing it any time soon. I've seen the attempts at scripting produced by in-experienced coders here You can't stop such people from crashing their systems by greping the word stop from their script. Have some faith in people man! Personally, any custom packages I make will start with this code: #!/bin/bash # keywords: start stop # The above line is in protest to wasting CPU cycles in checking inside my scripts every time. # For reference: http://lime-technology.com/forum/index.php?topic=6092.msg62376#msg62376 Seriously, what will happen if I now publish a crappy addon that messes up you system? Nothing is stopping me, right? People will scream that it messes them up, they'll post about it. They'll stop using it. Nobody will blame Limetech.
May 17, 201016 yr I reread the posts a few times, and I still can't see the benefit to having different "k" and "s" etc. scripts. Why don't we stick to the way Slackware does things? Even the simplest "rc.*" script can take parameters and act accordingly. Not different scripts, just links to one script. The one script still has to handle start/stop/restart/status. As far as I've seen, I do not think slackware blindly runs each script in /etc/rc.d There is rc.M. Naming things with an S or K in unraid.d helps lump them into a simpler method of drop and install. Drop a script named a certain way in a directory rather then updating an rc.? script with echo or sed. It could also allow us to have "other" internal run levels with the first character prefix. In any case, I'm all for simplicity. Doing a dirscan and execute is a simple approach.
May 17, 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. Our set of add-on tasks are just the newest on the list that must be performed in a specific order. Let me explain. Here are the actions that occur (greatly simplified, and with only one data drive, but you'll see what I mean hopefully) Unraid begins the process of starting the array performing the following steps: Create mount point directory /mnt/disk1 Mount the /dev/md1 drive on the mount point start SMBD Stopping it MUST be done in the opposite order stop SMBD un-mount the /dev/md1 device remove the mount point directory. Now, emhttp has the sequence hard-coded. An advantage when it controls everything. We wish to add our own orderly start and stop of add-ons. The sequence then looks like this: Create mount point directory /mnt/disk1 Mount the /dev/md1 drive on the mount point start SMBD Start add-ons Stopping it MUST be done in the opposite order Stop add-ons stop SMBD un-mount the /dev/md1 device remove the mount point directory. 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 start a database engine, then start a media service that uses it for a content library to serve via streaming protocol to a device on the LAN. To shut down, we would need to stop the streaming protocol service, then shut down the database, then handle other rc.* tasks needing to be "stopped" that may, or may not have a sequence that matters other than they must occur before the array disks can be un-mounted and the array can be stopped. So... our add-on tasks are actually just an extension of a problem that already exists, not a solution looking for a problem. Joe L.
May 17, 201016 yr The current 5.0 code is solving this through a 'registration' mechanism of the form: register <event name> <script name> <optional arguments> For example the script to install a plugin might include this: register ARRAY_START <name of script> register ARRAY_STOP <name of script> register DISK_DSBL <name of script> etc. When the corresponding event occurs, all scripts registered with that event are called with a per-event set of arguments. 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.
May 17, 201016 yr The current 5.0 code is solving this through a 'registration' mechanism of the form: register <event name> <script name> <optional arguments> For example the script to install a plugin might include this: register ARRAY_START <name of script> register ARRAY_STOP <name of script> register DISK_DSBL <name of script> etc. When the corresponding event occurs, all scripts registered with that event are called with a per-event set of arguments. 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. We could then work it several ways. We could register a single plug-in that in turn deals with all the dependencies and ordering of the multiple tasks, or register the individual tasks. Personally, I'll wait to state my final preference, but it all depends on what else happens when a registered script executes. From what I know so far, I'd personally like lime-tech to invoke just one task, to keep it simple for it, but if there can be multiple it just makes it more flexible for us. Tom, If multiple tasks are registered, are they stopped in reverse order of them being started? Or in the same order? (reverse order is by far better if there are dependencies ) Edit: It might be that the ARRAY_STOP events will execute in the order they are registered too... Joe L.
May 18, 201016 yr Looking at Tom's post closer, it appears as if the ARRAY_START and ARRAY_STOP must be separately registered. This will greatly complicate the registration of a dependent set of add-ons since you cannot register each add-on in turn in its entirety. We must register ARRAY_START database add-on register ARRAY_START add-on that uses database register ARRAY_STOP add-on that uses database register ARRAY_STOP database add-on. registration in the above order would allow the add-on that uses the database to be stopped prior to the database itself. We can't just register each add-on in turn, as that would result in register ARRAY_START database register ARRAY_STOP database add-on. register ARRAY_START add-on that uses database register ARRAY_STOP add-on that uses database Now, when we go to stop the server, we would stop the database first, since it was registered first, and the service that uses it next, since it was registered next. That would not be the best order to stop things. Joe L.
Archived
This topic is now archived and is closed to further replies.