unMENU plug-in: Go Script Manager

[Biggy2872]

Yesterday I spent some time with a Professor of Software Engineering who has lots of experience with linux at a local university.

 

I picked his brain for close to an hour and we discussed the best methods of implementing the features requested based on linux standards and came up with a few ways to deal with them.  I want to run them by everyone here to see if we can come up with a consensus.

 

In terms of booting order... A custom boot order option will be available regardless of which "mode" the boot script manager is operating (more on that in a minute).  He did however stress an absolute need to have a "default" boot order which is known to work.  This way if a user ever accidentally chose the wrong order, by removing the custom order file, we can return to a "stock" release(for the purposes of troubleshooting a custom boot order).  The custom boot order file once initiated (via a button on the interface) will be editable in both the interface graphically, or by Joe L's "Config View/Edit" plugin (although if edited this way, would require the boot manager to be run AFTER the modifications in order for them to be applied).  I will provide more details about this file at the time of release.

 

We also discussed alternatives to prepending S## and K## to the script for maintaining boot order and while many options were discussed, we ultimately decided that it would be important to stick with the linux convention for at the very least the following reasons: 1. runlevels (if and when we get them) 2. Advanced users are already using that convention and 3. the use of a single "rc.local" type file can be difficult to manage in the manner desired, especially if the user directly modifies this file.  The boot script manager could "lose control" over being able to add or subtract things from it because it can't find EXACTLY the code it is looking for in that file.

 

THE MODES

 

STOCK unRAID mode

 

First off, for people running a stock unraid (using the go script and NOT the /boot/custom/etc/rc.d folder).

 

The operation will be similar to the previous version of the go script manager.... That is to say when a package in enabled, an .auto_goscript file will be created in the package folder and run from an appended line in the go script on boot.

 

The actual contents of the .auto_goscript would mirror the contents of the script file placed into the /boot/custom/etc/rc.d in the folder as outlined below.

 

 

/boot/custom/etc/rc.d mode

In this mode there are three options we discussed, here are the details and the implications of each... Notice that in this method no lines need to be appended.  By virtue of the leading S##, the rc.startup script can run all the other scripts without the need to invoke them seperately from an appended line.

 

FIRST

 

The first is a "division of labour" approach whereby the script and the .conf are two sperate files.  The file created by the boot script manager (script file located in /boot/custom/etc/rc.d) would be a symlink or redirection to the actual script contents.  The scripts would be saved to either /boot/custom/bin or /boot/custom/etc/rc.d/init.d.  The latter being the linux standard place to put the scripts.

 

Implications:

for updating a script, you would just replace the old one with the new one in script folder and it is "automatically" upgraded to the new script without any need to do anything in the boot script manager.  The .confs in this method would remain "static".

 

SECOND

 

The second method is similar to the first, in that scripts will still be seperate from their .confs, however in this case, when a package is enabled, the script itself is copied over to the appropriate place by the boot script manager(file placed in /boot/custom/etc/rc.d).

 

Implications:

in this case when a script is updated as previously, by overwriting it in the script directory (/boot/custom/bin or /boot/custom/etc/rc.d/init.d).  On the first run of the boot script manager, it will notice that the script has changed and provide options to the user to "accept the new script" or "keep the old script" with the ability to view both and make an "informed" decision.

 

THIRD

 

That the .confs themselves contain the code for the script.  the contents are copied over to a script file in the /boot/custom/ect/rc.d and when a .conf is upgraded, it can compare it's contents with the "enabled" version of the script and automatically update or give the user the options to choose between the old code and new code on the next run of the boot script manager.

 

Implications:  it is harder to update scripts, you need to replace the entire .conf and if you have already edited a previous version of the .conf (making it non-standard from the distributed file), those changes would be lost when you overwrite the old modified .conf with the new distributed .conf.

 

 

of all these methods, the third is the easiest for me to program but is the alternative which is least attractive to me for its actual operation.  What do you guys think?  Which method do you prefer?

 

Another feature we talked about and I have mentioned before, is the automatic .conf generation.  briefly, the feature goes like this... If the boot script manager finds scripts installed in /boot/custom/etc/rc.d that it cannot associate with one of the distributed .confs, it will create a new .conf with a default name and descriptions suggesting to the user to edit it with valid information.  This .conf will allow for control over that script by the boot script manager.  This will also help in sharing of scripts, once the user has filled in the appropriate information, they could then share the .conf and script files for others to enjoy (it takes some of the pain out of making new .confs by not needing to do it from scratch, typically only the name and description will need to be adjusted).

 

I know there was some concern over the way in which the program and .confs were distributed, in the future this is what I will do... First the OP will contain the instructions and program package to download.  The second post in the thread will be dedicated to the "unofficial - official .confs" to display the contents and allow for the .confs to be updated seperately between program version releases.  the date of the latest update for each script will be included.  I will also edit the wiki to include this information (sans links) and update it as often as possible.  Will this be enough or does someone want me to do it differently?  I could lock the thread and start another one for comments/suggestions/bugs, but that seems like a waste to me, you'll always be able to look for the downloads in the first two posts (they won't be anywhere else in the thread, at least not by me).

 

I have one last question and it is directed a little more towards Joe L, but others can feel free to respond too... should I FORCE the use of the third party architecture or use global variables for the location of script files?  That is to say that the scripts MUST be in /boot/custom/etc/rc.d/init.d (for example) or allow the users to define a variable like BOOT_SCRIPT_DIRECTORY in unmenu_local.conf?  This is only important if we decided to have the .confs and scripts seperate.

 

Looking forward to some feedback,

Matt

[Biggy2872]

Instead of trying to standardize the numbers, you might consider creating a set of reusable startup scripts.  And have the boot script manager create short little script files that call those scripts.

 

I think this is clear but the numbers are used as the ordering mechanism.  The lower the number, the earlier in the sequence it is executed.  In my system, S05 is a 30 second sleep.  A script with a number less that S05 happens before the sleep, greater thatn S05 happens after the sleep.  The 30 second sleep allows unRAID to bring the array online so that you can be reasonably sure that the drives are mounted and Samba is configured.

 

If you give two scripts the same number, subsequent characters will determine the colating sequence.  I have used the same number when I really didn't care which one executed first.  Perhaps you want to avoid this.

 

My scripts in this directory tend to be very short.  If I am doing anything complex, the script just calls another script.  For example, I get a smart report on every boot. This is in a separate script and called.

 

I was writing a long message as you posted, you might want to look it over and I think I mention a method similar to what you are talking about... likely the first or second with some small modifications.

 

Cheers,

Matt

[prostuff1]

In terms of booting order... A custom boot order option will be available regardless of which "mode" the boot script manager is operating (more on that in a minute).  He did however stress an absolute need to have a "default" boot order which is known to work.  This way if a user ever accidentally chose the wrong order, by removing the custom order file, we can return to a "stock" release(for the purposes of troubleshooting a custom boot order).  The custom boot order file once initiated (via a button on the interface) will be editable in both the interface graphically, or by Joe L's "Config View/Edit" plugin (although if edited this way, would require the boot manager to be run AFTER the modifications in order for them to be applied).  I will provide more details about this file at the time of release.

 

We also discussed alternatives to prepending S## and K## to the script for maintaining boot order and while many options were discussed, we ultimately decided that it would be important to stick with the linux convention for at the very least the following reasons: 1. runlevels (if and when we get them) 2. Advanced users are already using that convention and 3. the use of a single "rc.local" type file can be difficult to manage in the manner desired, especially if the user directly modifies this file.  The boot script manager could "lose control" over being able to add or subtract things from it because it can't find EXACTLY the code it is looking for in that file.

Glad you could could pic the brain of someone outside this little community.  I tend to agree with everything that you say above.  I think sticking with what is already set up is a good thing.  Since unRaid is a Linux distro I think we need to keep it as close to that as possible. The use of S## for the front of the script SHOULD continue.  It gives a baseline for the novice user (and help with diagnosing a problem), while still allowing the more experienced user to move stuff around.

 

THE MODES

 

STOCK unRAID mode

 

First off, for people running a stock unraid (using the go script and NOT the /boot/custom/etc/rc.d folder).

 

The operation will be similar to the previous version of the go script manager.... That is to say when a package in enabled, an .auto_goscript file will be created in the package folder and run from an appended line in the go script on boot.

 

The actual contents of the .auto_goscript would mirror the contents of the script file placed into the /boot/custom/etc/rc.d in the folder as outlined below.

 

 

/boot/custom/etc/rc.d mode

In this mode there are three options we discussed, here are the details and the implications of each... Notice that in this method no lines need to be appended.  By virtue of the leading S##, the rc.startup script can run all the other scripts without the need to invoke them separately from an appended line.

 

FIRST

 

The first is a "division of labour" approach whereby the script and the .conf are two sperate files.  The file created by the boot script manager (script file located in /boot/custom/etc/rc.d) would be a symlink or redirection to the actual script contents.  The scripts would be saved to either /boot/custom/bin or /boot/custom/etc/rc.d/init.d.  The latter being the linux standard place to put the scripts.

 

Implications:

for updating a script, you would just replace the old one with the new one in script folder and it is "automatically" upgraded to the new script without any need to do anything in the boot script manager.  The .confs in this method would remain "static".

I like the fact that the .conf files do not need to be updated.  The easier we can make it fr the novice user the better.

 

SECOND

 

The second method is similar to the first, in that scripts will still be seperate from their .confs, however in this case, when a package is enabled, the script itself is copied over to the appropriate place by the boot script manager(file placed in /boot/custom/etc/rc.d).

 

Implications:

in this case when a script is updated as previously, by overwriting it in the script directory (/boot/custom/bin or /boot/custom/etc/rc.d/init.d).  On the first run of the boot script manager, it will notice that the script has changed and provide options to the user to "accept the new script" or "keep the old script" with the ability to view both and make an "informed" decision.

This i like even more.  I think something needs to be done so that we get everyone using the same system (even if it is a little by force) and places to store things like scripts.  I like the option of showing the user about the script change and the fact that they can choose to accept it or not.

 

THIRD

 

That the .confs themselves contain the code for the script.  the contents are copied over to a script file in the /boot/custom/ect/rc.d and when a .conf is upgraded, it can compare it's contents with the "enabled" version of the script and automatically update or give the user the options to choose between the old code and new code on the next run of the boot script manager.

 

Implications:  it is harder to update scripts, you need to replace the entire .conf and if you have already edited a previous version of the .conf (making it non-standard from the distributed file), those changes would be lost when you overwrite the old modified .conf with the new distributed .conf.

Not a huge fan of this, i think the .conf files and scripts should be separate.

 

of all these methods, the third is the easiest for me to program but is the alternative which is least attractive to me for its actual operation.  What do you guys think?  Which method do you prefer?

I think the ideal option would be number 2.  When the update message comes up in Boot Script Manager it would be nice to have a side by side view of both scripts so that any changes that were made to the previous version could be copied from one to the other. I think something like this could come in very handy for the people that change certain parts of any given script.

 

Another feature we talked about and I have mentioned before, is the automatic .conf generation.  briefly, the feature goes like this... If the boot script manager finds scripts installed in /boot/custom/etc/rc.d that it cannot associate with one of the distributed .confs, it will create a new .conf with a default name and descriptions suggesting to the user to edit it with valid information.  This .conf will allow for control over that script by the boot script manager.  This will also help in sharing of scripts, once the user has filled in the appropriate information, they could then share the .conf and script files for others to enjoy (it takes some of the pain out of making new .confs by not needing to do it from scratch, typically only the name and description will need to be adjusted).

I think this is a good idea.  .conf files are something that we need to start using for all scripts, if for no other reason then to make it more clear to the novice.

 

I know there was some concern over the way in which the program and .confs were distributed, in the future this is what I will do... First the OP will contain the instructions and program package to download.  The second post in the thread will be dedicated to the "unofficial - official .confs" to display the contents and allow for the .confs to be updated separately between program version releases.  the date of the latest update for each script will be included.  I will also edit the wiki to include this information (sans links) and update it as often as possible.  Will this be enough or does someone want me to do it differently?  I could lock the thread and start another one for comments/suggestions/bugs, but that seems like a waste to me, you'll always be able to look for the downloads in the first two posts (they won't be anywhere else in the thread, at least not by me).

I would be willing to help with the updating of the wiki.  I don't really have a lot of programming skills to offer but i am willing to help keep stuff organized.  I have not really done any wiki editing before but i figure i might as well start now and try to help out all the people that are doing the realy work.  As long as I get PM's with links to the appropriate post(s) (so i don't have to hunt and search for the stuff) i don't mind helping.

 

I have one last question and it is directed a little more towards Joe L, but others can feel free to respond too... should I FORCE the use of the third party architecture or use global variables for the location of script files?  That is to say that the scripts MUST be in /boot/custom/etc/rc.d/init.d (for example) or allow the users to define a variable like BOOT_SCRIPT_DIRECTORY in unmenu_local.conf?  This is only important if we decided to have the .confs and scripts separate.

Well, this is a tough question and one that i think needs to be answered sooner rather then later.  I am almost positive that forcing this Third Party Boot Architecture (TPBA) would make it easier for the programmers to do what they needed to do.  If they know a structure,  the TPBA, is going to be there then that is one less thing they to worry about.  You would not have to mess with the .auto_install stuff anymore.  Perhaps putting a little option in the very top corner of the Boot Script Manager that would say "use current folder architecture" and another one that says "use TPBA" with the later being the one that is on by default. Maybe this could be a little pop-up box that gives this message when Boot Script manager is launched for the first time (obviously some links would need to be included along with the suggestion that the TPBA be the suggested method for installing scripts).

 

 

Well, that is my $.02 so i will leave it there for now

[RobJ]

I would be willing to help with the updating of the wiki.

 

  Yes!    Woot woot woot!!!      Right ON!!!        Anyone else want to help???  ;D

[prostuff1]

I would be willing to help with the updating of the wiki.

 

   Yes!      Woot woot woot!!!       Right ON!!!           Anyone else want to help???    ;D

 

Glad I could make someone's day!

[Biggy2872]

First, thank you prostuff1 and bjp999 for your messages.

 

I think for the time being, I am going to program for method 1.  The goal will be to eventually have hybrid of method 1 and 2, but I have to deal with a few issues to get the updating procedures working the way I want them.  So for at least the first release of the boot script manager, it will use the "automatic update".  I will include ample warning about being vigilant in overwriting scripts with new ones in the documentation until I can provide reliable user updating options in the interface.  The issue I'm trying to work through is that if the script is overwritten, the new version will be automatically used on next boot until the change is reverted in the boot script manager. I want the behaviour to be opposite, meaning the update has to be accepted before it is changed.

 

I would be willing to help with the updating of the wiki.  I don't really have a lot of programming skills to offer but i am willing to help keep stuff organized.  I have not really done any wiki editing before but i figure i might as well start now and try to help out all the people that are doing the realy work.  As long as I get PM's with links to the appropriate post(s) (so i don't have to hunt and search for the stuff) i don't mind helping.

 

I would like to take you up on this offer, I would PM you the program details, updated packages with some documentation and help by writing things you think I might be better suited to write.  I would ask that you take some time to edit the information I give you and ensure continuity in the wiki.  The best wiki editing advice I was ever given is to be BOLD.  If you are trying to decide wether to include something, elect to do it.  Things can always be edited/moved around later. 

some other good pointers are:

- Get all the important information in first and then try and "fluff" it with the details/examples.

- Sometime a well planned table, chart, photo or diagram will provide more information in a much smaller area then trying to explain it in words (and be much clearer)

- Don't be affraid to re-organize the information if after time you decide a better way to present it.

- wikis are not meant to be "static" in the sense that they are written and forgot about.  Things change over time and the information and format in the wiki are intended to change with them. 

 

I would also ask that you try and write some additional documentation in terms of usage of the program yourself.  The reason I think this is important is that sometimes another user can provide better, easier to follow instructions based on their own experiences with the program.  I know I will tend to complicate instruction by providing too much information and have a hard time editing myself to be more concise.  I could provide you the details of "how to break something" intentionally, then provide a few methods to try to correct it and you can find the easiest "tried and true" method from those suggested and report the solution on the wiki.  This would not take too much time, likely only a few minutes, but would make you an expert in the solution (nobody else would have done it yet, so you would have the most experience)

(Note: by breaking something intentionally, i don't mean to actually break things you have working, but provide you with "dummy" files to work with that won't harm your system or current booting scripts and that can be safely deleted after you are done using them)

 

You could also report major updates to the wiki in the boot script manager thread to keep people informed that it is there and what kind of things have been added to it.  Much like RobJ does when he updates the wiki to include information.

 

 

In terms of the TPBA, I will go so far as to force the use of a init.d subfolder (if there are not any objections?!?!) of the user defined rc.d directory in unmenu_local.conf.  For almost everyone that has a rc.d folder(and anyone using the stock go file approach), this would mean /boot/custom/etc/rc.d/init.d.  I could include a search of /boot/custom/bin for S##-* files and move them by default to the new folder for those who use this folder for scripts and redirect to them from the rc.d folder.

 

I also wanted to mention something which I could see as a problem with the custom boot order.  If we had a script say: S75-ftp_conf which has one line cp /location/of/needed.conf /location/of/useless.conf which is designed to force the use of a particular configuration file in a package manager installed program.  The problem is that if i set the boot script S75-ftp_conf BEFORE S10-custom_install_packages in a custom boot order, then the needed.conf would be copied first, the program is installed later when S10-custom_install_packages in invoked, which will overwrite the needed.conf with the useless.conf and the package manager installed program will not function as expected.  People using custom boot orders will have to understand this limitation.  I will not release scripts which will directly effect a package manager installed program (but it is possible for someone to have a created a custom boot script manager package) and would suggests that those scripts be included as additional PACKAGE_INSTALLATION lines in the appropriate *-unmenu-package.conf file. (NOTE this problem will still exist if the changes are made via sed commands or any other equivalent method in the script, the problem is in the order of execution and not the contents of the script.)  I call this the "USER GENERATED DEPENDENCY PROBLEM".  I have some thoughts on how to work around this problem but it will not be available as a working feature in the first release which is why I mention it now.

 

Cheers,

Matt

[jimwhite]

another vote for method 2

 

[Joe L.]

another vote for method 2

 

And one more for migrating toward a more consistent use of /boot/custom/etc/rc.d...

 

I never intended to force everyone to use a /boot/custom/etc/rc.d folder, but I have no issue with migrating to that as the unofficial-official standard.   A really experienced developer will do as they please, and less experienced really won't care as long as they don't have to do much at the linux command line.

 

I do like keeping the "S" # # notation, as that is very common across many versions of UNIX/Linux.  (We'll get the "K" ## scripts too once we have the needed hooks into emhttp to know when it is shutting down (stopping) the array.)

 

The numeric notation will let experienced users know at a glance the order of execution...   

 

I have no issue with links from an init.d directory with the base named scripts.  That way, the system you put into place to manage the links from /boot/custom/etc/init.d to boot/custom/etc/rc.d can do all the hard work.

Only issue I see is the flash drive probably will not allow you to create links, as it is a FAT file-system.  If you have to copy the scripts from init.d to rc.d, it would negate the whole benefit of init.d.

 

Joe L.

[Biggy2872]

Only issue I see is the flash drive probably will not allow you to create links, as it is a FAT file-system.  If you have to copy the scripts from init.d to rc.d, it would negate the whole benefit of init.d.

 

This is what I envisioned long-term... When runlevels/shutdown hooks are available.

 

The individual scripts would be updated to accept the "start","stop" ... commands

 

The S file contents in /boot/custom/etc/rc(#).d  would be

/boot/custom/etc/rc.d/init.d/S75-Script_to_run Start

 

and the K file would be

/boot/custom/etc/rc.d/init.d/K75-Script_to_run Stop

 

FOR NOW it would just be an S file with this:

/boot/custom/etc/rc.d/init.d/S75-Script_to_run

 

not as nice of a solution as being able to symlink but i think it will serve our needs.

 

Matt

[Joe L.]

Only issue I see is the flash drive probably will not allow you to create links, as it is a FAT file-system.  If you have to copy the scripts from init.d to rc.d, it would negate the whole benefit of init.d.

 

This is what I envisioned long-term... When runlevels/shutdown hooks are available.

 

The individual scripts would be updated to accept the "start","stop" ... commands

 

The S file contents in /boot/custom/etc/rc(#).d  would be

/boot/custom/etc/rc.d/init.d/S75-Script_to_run Start

 

and the K file would be

/boot/custom/etc/rc.d/init.d/K75-Script_to_run Stop

 

FOR NOW it would just be an S file with this:

/boot/custom/etc/rc.d/init.d/S75-Script_to_run

 

not as nice of a solution as being able to symlink but i think it will serve our needs.

 

Matt

That is about how I envisioned it too..

 

We do need to be eventually able to stop and start specific jobs when the array is stopped and started, not just when it is booted.

 

So, you might "stop" your torrent process before the array is stopped, and start it after the array is re-started, but you would not need to re-start, or stop the "S130-schedule-monthly-parity-check" job I currently have installing every time I reboot.

 

Eventually, we need a way to trigger specific tasks as various times as the array is booted, stopped, and re-started.

 

The time to discuss this is now... Glad you are thinking ahead.

[JarDo]

Well, it's been a long time since I rebooted my server with the go script manager enabled.  But I thought I should try it again.  The last time I tried I thought that it was hanging my server.  The only script I have enabled is the one to execute "uu" (to enable unMenu).

 

PACKAGE_NAME Start unMENU
PACKAGE_DESCR Script to start unMENU v1.1 at boot up via the uu script in the unMENU folder
PACKAGE_INSTALLATION /boot/unmenu/uu

 

From the console it appears that my server is stopped at the point where S10-install_custom_packages script is looking for and installing any *.auto_goscript files that it can find.  I can telnet to my server and I can access unmenu so it appears that the go script manager did manage to run the "uu" script. 

 

But, at my console I don't have a prompt.  It appears to be stuck.  I tried rebooting a couple of times but the symptom is repeatable.

 

Any ideas???

[Biggy2872]

Well, it's been a long time since I rebooted my server with the go script manager enabled.  But I thought I should try it again.  The last time I tried I thought that it was hanging my server.  The only script I have enabled is the one to execute "uu" (to enable unMenu).

 

PACKAGE_NAME Start unMENU
PACKAGE_DESCR Script to start unMENU v1.1 at boot up via the uu script in the unMENU folder
PACKAGE_INSTALLATION /boot/unmenu/uu

 

From the console it appears that my server is stopped at the point where S10-install_custom_packages script is looking for and installing any *.auto_goscript files that it can find.  I can telnet to my server and I can access unmenu so it appears that the go script manager did manage to run the "uu" script. 

 

But, at my console I don't have a prompt.  It appears to be stuck.  I tried rebooting a couple of times but the symptom is repeatable.

 

Any ideas???

 

This is the 30 second delay I put into the booting process to make sure things are running before executing scripts... wait it out, it happens on my system too... you'll get a prompt after the 30 seconds elapses, I promise....

 

Matt

 

ps... the new version of the boot script manager will act differently in this regard in the future... the go script manager was a good way for me to learn what i needed to do, but doesn't necessarily do it in the best of methods(in retrospect) and one of the reasons it is getting overhauled.

[JarDo]

It's now the next day.  I'm using my server, and it is calculating parity.  I can access the web interface(s) and can telnet.  It seems that the console will show a new message every now and then.  The latest is "nmbd - no process killed".  (I don't know what that means.) But, still no prompt at the console.

[Biggy2872]

It's now the next day.  I'm using my server, and it is calculating parity.  I can access the web interface(s) and can telnet.  It seems that the console will show a new message every now and then.  The latest is "nmbd - no process killed".  (I don't know what that means.) But, still no prompt at the console.

 

What I would suggest is removing the goscript manager (it will be replaced in the next few weeks by a much better version) and delete the file zzz.auto_install in your package folder (leave the unMENU-...auto_goscript), it will still try and run unmenu for you at start-up.  See if that gets rid of the problem (this will tell me if it is the zzz.auto_install file causing the problems as I suspect).

 

Cheers,

Matt

[JarDo]

Well, I deleted the zzz.auto_install and deleted the goscript manager from my unMenu menu.  Still, the boot would not complete to a command prompt.  The only script I had enabled prior to removing the goscript manager from my unMenu menu was the one that executed 'uu'.  'uu' still executed.  Even though the boot process never completed to a prompt, I was able to log into unMenu via a browser.  Next, I re-installed the goscript manager, disabled the goscript that executed 'uu', and then placed the command to execute 'uu' directly into my go script.  Upon reboot everything worked just fine.

 

I think I'm just going to wait until the next release of the goscript manager before I try additional testing.

[Biggy2872]

Well, I deleted the zzz.auto_install and deleted the goscript manager from my unMenu menu.  Still, the boot would not complete to a command prompt.  The only script I had enabled prior to removing the goscript manager from my unMenu menu was the one that executed 'uu'.  'uu' still executed.  Even though the boot process never completed to a prompt, I was able to log into unMenu via a browser.  Next, I re-installed the goscript manager, disabled the goscript that executed 'uu', and then placed the command to execute 'uu' directly into my go script.  Upon reboot everything worked just fine.

 

I think I'm just going to wait until the next release of the goscript manager before I try additional testing.

 

AHA! figured it out....

 

The problem was likely in .auto_goscript file with the line to call the uu script... If I remember correctly I had an error in the original script and unless you BOTH replaced the .conf and then disabled and re-enable the package via the go script manager, the original error would still have been in the .auto_goscript file that your program would run on boot...

 

Specifically the problem was that the last line in the .conf was the final PACKAGE_INSTALLATION line that did not contain a cr/lf pair or a lf (I didn't hit enter on the last line when I made the .conf..) As a result, you don't get the command line back (from my understanding of hours of searching google).  When I found the problem, I fixed it and I re-issued a new .conf for that package... I'm almost 100% sure that is what happened to you, you populated the .auto_goscript file with the correct code minus the line feed when you originally enabled the package with the included .conf and then if/when you replaced the .conf with the correct version, you did not disable(deletes the incorrect .auto_goscript) and re-enable(re-creating the .auto_goscript file with the new corrected line) the script.  The error came about because at the time I was not running v1.1 of unmenu(no uu script in v1.0) and could not test it properly.  I'm sorry about this and will make every effort to avoid these kinds of problems in the future. 

 

Again, I'm sorry and I hope that explains what went wrong,

Matt

[JarDo]

Actually, I had already been working on that theory.  Just the same.  I double-checked that my unMENUstart-unmenu-goscript.conf contains a cr/lf at the end of the very last line (a blank line at the end of the file).  I removed the command from my go script to execute 'uu'.  I enabled the unMENUstart-unmenu-goscript.conf goscript from within the goscript manager.  And, now I'm rebooting.  Let's see what happens.

[JarDo]

Nope.  Still hangs and doesn't give me a prompt at the console.  Everything else is OK.  Did I understand your theory correctly?  Did I miss a step?

[Biggy2872]

Nope.  Still hangs and doesn't give me a prompt at the console.  Everything else is OK.  Did I understand your theory correctly?  Did I miss a step?

Nope, it sounds as if you did everything correctly...

 

I wish I could figure out why it works on my system and not yours.... We are running the same code on boot up... I'm using unRAID v4.3.3, you?

 

I just want to clarify and make sure I understand 100%, there will be a pause of about 30 seconds between when the last package manager package installs until the prompt shows up.. for me it's about 30 seconds.. for you it might be a full minute (30 second delay in a rc.d script before S10-custom_install_packages is run and then a 30 second delay before boot scripts are run).  You still don't get a prompt if you wait 1+ minutes?

 

I rebooted my system 3 times with a monitor plugged in (since your message at 7:42pm EST) and have gotten the prompt each time...

 

I guess you'll have to wait for the next version (Boot Script Manager), and because you have a /boot/custom/etc/rc.d folder, you will not need to worry about the .auto_goscript and the zzz.auto_install files anymore.  Hopefully that will straighten things out for you.  I'm still very curious as to why it is not working though...

 

Cheers,

Matt

 

EDIT: Has anyone else seen this behaviour?  Are there others running this script with no problems, like me?  Maybe we can find a commonality...

[jimwhite]

Has anyone else seen this behaviour?

Yes.... I often see ths in my many script incarnations...

 

[JarDo]

Matt,  Thank you for your continued consideration of this issue because I really, really want for the Go Script Manager to functinon for me.  As it stands right now, I am running v4.4.2 and no matter how long I wait (hours, days) I never get a to a command prompt when I'm using the Go Script Manager.  I think I'll just wait for the next version and start my testing all over at that time.

[JarDo]

Would it work to place 'IF' statements in a goscript.conf, or do we have to write our goscript.conf as if executing one command at a time at the prompt.  I'm trying to figure out if the .auto_goscript files created from a goscript.conf are run like a shell script or 'line by line'.

[Biggy2872]

Would it work to place 'IF' statements in a goscript.conf, or do we have to write our goscript.conf as if executing one command at a time at the prompt.  I'm trying to figure out if the .auto_goscript files created from a goscript.conf are run like a shell script or 'line by line'.

 

Can you give me an example of what you are talking about... I'm pretty sure I know, but I want to confirm it with an example please...

 

the go script manager makes a script file out of the PACKAGE_INSTALLATION lines... so if you wanted a script that looks like this:

 

#This is a dummy program that does nothing
if [(cond)];
then
  echo "cond is met"
else
  echo "cond is not met"
fi

 

would appear like this in a .conf:

 

PACKAGE_INSTALLATION #!/bin/bash
PACKAGE_INSTALLATION #This is a dummy program that does nothing
PACKAGE_INSTALLATION if [(cond)];
PACKAGE_INSTALLATION then
PACKAGE_INSTALLATION echo "cond is met"
PACKAGE_INSTALLATION else
PACKAGE_INSTALLATION echo "cond is not met"
PACKAGE_INSTALLATION fi

 

hope that answers your question.

 

Cheers,

Matt

 

 

 

[JarDo]

Yep,  It worked like a charm.  Thank you Matt.