New powerdown script needed for 5.0 unRAID

Agree -- getting the main issues with "stock" UnRAID is all that really matters.  If it's rock-solid, then it's ready for prime time (i.e. v5.0 "final").    Issues with plug-ins and add-ons can be resolved another day !!

 

... although I must confess I'd be very disappointed if we didn't at least have UPS support !!  (the only reason I install UnMenu is for this & the related CleanPowerDown package)

 

 

We can change the powerdown package.  If emhttp is running, it can communicate with emhttp and send the appropriate button presses then wait for emhttp to unmount the filesystems. 

The real reason it was created was to kill of any processes that had the disks mounted and unmount them as a last ditch effort.

Agree -- getting the main issues with "stock" UnRAID is all that really matters.  If it's rock-solid, then it's ready for prime time (i.e. v5.0 "final").    Issues with plug-ins and add-ons can be resolved another day !!

 

... although I must confess I'd be very disappointed if we didn't at least have UPS support !!  (the only reason I install UnMenu is for this & the related CleanPowerDown package)

The problem is when a process is keeping a disk busy and emhttp will wait forever to be able to un-mount a disk.  Therefore, handing complete control to emhttp is not the best solution. 

 

I think we need to create a new clean-powerdown plugin.  (as an alternative to the current package)

 

    add a "event" script in the new plugin to set an array status file to the current status in /var/tmp

    This file will let us know if emhttp is processing the events as expected. 

    By using the file contents, we do not have to query /proc/mdcmd. 

   

    when the new "clean powerdown" is invoked:

    if emhttp is running and responding

      invoke the power down "button" URL using wget

  x=60

  while x > 0

  do

      sleep 1

      x = x - 1

      if array status (in the above file) is stopped, exit loop

  done

 

  At this point, we've given emhttp 60 seconds time to stop the add-ons and un-mount the drives, etc.If it completed the task in less time, we are here and the status file should show the array is stopped/powering down the array.  we probably don't need to do anything more.

 

If still trying to un-mount the disks, then we can selectively kill processes holding them busy, and enter another while loop waiting for additional time for unRAID to un-mount the disks.

 

If the timers expire, and the disks are still not un-mounted, then we can proceed without emhttp figuring it is no longer doing all that is needed.

 

We can change the powerdown package.  If emhttp is running, it can communicate with emhttp and send the appropriate button presses then wait for emhttp to unmount the filesystems. 

The real reason it was created was to kill of any processes that had the disks mounted and unmount them as a last ditch effort.

Agree -- getting the main issues with "stock" UnRAID is all that really matters.  If it's rock-solid, then it's ready for prime time (i.e. v5.0 "final").    Issues with plug-ins and add-ons can be resolved another day !!

 

... although I must confess I'd be very disappointed if we didn't at least have UPS support !!  (the only reason I install UnMenu is for this & the related CleanPowerDown package)

The problem is when a process is keeping a disk busy and emhttp will wait forever to be able to un-mount a disk.  Therefore, handing complete control to emhttp is not the best solution. 

 

I think we need to create a new clean-powerdown plugin.  (as an alternative to the current package)

 

    add a "event" script in the new plugin to set an array status file to the current status in /var/tmp

    This file will let us know if emhttp is processing the events as expected. 

    By using the file contents, we do not have to query /proc/mdcmd. 

   

    when the new "clean powerdown" is invoked:

    if emhttp is running and responding

      invoke the power down "button" URL using wget

  x=60

  while x > 0

  do

      sleep 1

      x = x - 1

      if array status (in the above file) is stopped, exit loop

  done

 

  At this point, we've given emhttp 60 seconds time to stop the add-ons and un-mount the drives, etc.If it completed the task in less time, we are here and the status file should show the array is stopped/powering down the array.  we probably don't need to do anything more.

 

If still trying to un-mount the disks, then we can selectively kill processes holding them busy, and enter another while loop waiting for additional time for unRAID to un-mount the disks.

 

If the timers expire, and the disks are still not un-mounted, then we can proceed without emhttp figuring it is no longer doing all that is needed.

 

We can change the powerdown package.  If emhttp is running, it can communicate with emhttp and send the appropriate button presses then wait for emhttp to unmount the filesystems. 

The real reason it was created was to kill of any processes that had the disks mounted and unmount them as a last ditch effort.

 

Sounds like a GREAT idea Joe !!  Now which one of you Linux gurus is going to write it ??  8)

... I'm a total non-Linux guy, so I'm afraid I can't help with this.  I just want to select it in UnMenu and have it work right !!  ... 100% of the time 

+1  Rock solid, stable, and just works.    Virtually all of the issues noted on this forum (certainly the vast majority) are caused by add-ons ... NOT by the core functionality.

In the market for small home NAS solutions, people are looking for certain capabilities, which in unRaid's case are possible only through add-ons. So the way you draw the line what's "core functionality" makes the difference between people buying your product or somebody else's.

 

Certainly agree => with any consumer product there are features some will want while others don't need them.    But every product has some set of built-in features ... and in UnRAID's case that is essentially a NAS that can mix disk sizes and interfaces and provide single-disk-failure fault-tolerance.  It does those tasks very well.  Certainly if you need additional features; and don't want to provide them by simply running a Linux or Windows box that provides the additional features while using an UnRAID NAS for storage, then whether or not those functions can be safely provided by UnRAID is a factor.    But many on this forum have recognized the importance of a rock-solid storage core; and are building ESXi systems with a basic UnRAID system running as a virtual instance; with another Linux (or Windows) OS running in another VM that's providing all of the additional capabilities they want.   

I do agree that it would be beneficial to all if Tom could provide a 'Safe-Mode' boot option, allowing all users to easily test unRAID beta and release candidates without incompatible plug-ins/add-ons/code-replacements.  On the flip side, if you're not capable of booting stock-unRAID, perhaps you shouldn't be running these RC's.  Think about it:  this is brand new unRAID code, new to even the authors of the add-ons, and their code may not have been updated in years, much less for the most recent RC that came out mere days ago.

 

yeah - that makes lots of sense. We want to extend Unraid because we can. But at the same time, that's a big selling point - that you can extend beyond the stock, if you are a power user.

 

OR, if dev cycles can be kept shorter, completely disable add-on support until a stable release is achieved. Get developers access throughout dev. cycle to work on their add-ons, but prevent end-users from doing so until outstanding issues are ironed out.

 

That helps achieve the goal of only developers reporting the major issues to Tom - leaving time to focus on UnRaid dev.

I 100% agree that users should test with no add-ons enabled.  That however, is harder to get some to do, as their entire server/media  playback depends on the add-ons.

 

I do recognize that an add-on from 8 years ago might work differently today, and have different results.  I know I constantly monitor for such issues.    The "powerdown" script came to be because unRAID would hang waiting for disks to be un-mounted.  The shell script "powerdown" existed considerably BEFORE lime-technology decided to put into place a similarly named command line utility with the same name as WeboTech's "powerdown" and put it prior to WeeboTech's in the command PATH.

 

The issue was, when you typed "powerdown", which command would run?  Most unRAID users are not linux-savy enough to use the full path.    Most wuld only type the command when they lost the ability to reach the system web-management console.  In defense of the "powerdown" command, lime-technology is the offender, replacing a user-created utility with one that was useful only if all the disks could be un-mounted, and not usable in a power failure.  Tom should have named his command "unraid_powerdown" (or something similar) or, Tom should have included a "--force" option to it to request it to kill processes holding disks busy.

 

When the original "powerdown" was written, the only user of the command was the apcupsd command to assist in cleanly shutting down the server in the event of a power failure.  The lime-tech supplied alternative is NOT usable, as it is written.

 

We are getting way off track here, so I think I might split off this set of messages so this thread can get back t 5.0rc13 issues.

 

Joe L.

Nicely stated Paul => in addition to customizing cars, there's a lot of technology that gets done as well ... note the online communities to "jailbreak" locked phones, tablets, etc. => you can indeed do more with them than the "stock" versions -- but the manufacturer is certainly not going to provide support if you have issues !!

 

Joe & WeeboTech =>  I may be wrong, but it seems to me you two are the most knowledgeable guys to coordinate on building us a nice new Powerdown script 

... and if it was automated through UnMenu that would be even nicer (so those of us total Linux idiots could just "click" to use it 

They have also included "clean power down" script in APCUPS plugin, maybe that is a bad idea, this should be a standalone package, that was I think, if there would be some updated, the plugins also need to be changed or been removed from the plugin.

 

//Petre

They have also included "clean power down" script in APCUPS plugin, maybe that is a bad idea, this should be a standalone package, that was I think, if there would be some updated, the plugins also need to be changed or been removed from the plugin.

 

//Petre

 

Actually I don't think it's in the APC package => at least in the UnMenu package manager you have to select them both [There IS a note for the APC package that tells you to also select CleanPowerDown -- but it's not automatically selected].

 

The plugin have this embedded, I'm not referring to unmenu packages.

 

//Peter

The plugin have this embedded, I'm not referring to unmenu packages.

 

Ah ... didn't realize there was a separate plugin.  Is it a newer/different version than UnMenu installs?    Any reason to favor one over the other?

 

 

The plugin have this embedded, I'm not referring to unmenu packages.

 

Ah ... didn't realize there was a separate plugin.  Is it a newer/different version than UnMenu installs?    Any reason to favor one over the other?

as far as I know, it is the same.  Unfortunately, some plugin authors have chosen to embed our scripts in their plugins to try to make it easier. Initially, it does, then when updates are needed, it all falls apart.  When I first wrote the package manager in unMENU, it was designed so multiple sets of configuration lines for multiple packages could exist in a single .conf file.  I quickly adopted one package per .conf file once changes and updates were needed.  It was WAY easier.  It is why the apcupsd and clean-powerdown are separate packages, as are "ssmtp" and "mailx"

 

What is needed is a centralized repository for the modules, and a method to indicate dependencies.

 

It gets really complicated, because the newer-best-thing-since-sliced-bread-module today that solves a problem can become one that causes an issue in a subsequent newer release of unRAID.   

 

Joe L.

When you install an actual slackware package, it puts a file in in /var/log/packages.

 

This can be tested for dependancy.

root@unRAID1:/var/log/packages# ls -l

total 8

-rw-r--r-- 1 root root 2091 2013-06-09 15:37 screen-4.0.3-i486-1

-rw-r--r-- 1 root root  802 2013-06-09 15:37 utempter-1.1.4-i486-1

 

There is also.

 

root@unRAID1:/var/log/packages# cat /etc/unraid-version

version=5.0-rc12a

When you install an actual slackware package, it puts a file in in /var/log/packages.

 

This can be tested for dependancy.

root@unRAID1:/var/log/packages# ls -l

total 8

-rw-r--r-- 1 root root 2091 2013-06-09 15:37 screen-4.0.3-i486-1

-rw-r--r-- 1 root root  802 2013-06-09 15:37 utempter-1.1.4-i486-1

 

There is also.

 

root@unRAID1:/var/log/packages# cat /etc/unraid-version

version=5.0-rc12a

/etc/unraid-version is fairly new.  It does not exist in the 4.7 version of unRAID.  I don't remember where in the 5.X series it was introduced.

When you install an actual slackware package, it puts a file in in /var/log/packages.

 

This can be tested for dependancy.

root@unRAID1:/var/log/packages# ls -l

total 8

-rw-r--r-- 1 root root 2091 2013-06-09 15:37 screen-4.0.3-i486-1

-rw-r--r-- 1 root root  802 2013-06-09 15:37 utempter-1.1.4-i486-1

 

There is also.

 

root@unRAID1:/var/log/packages# cat /etc/unraid-version

version=5.0-rc12a

/etc/unraid-version is fairly new.  It does not exist in the 4.7 version of unRAID.  I don't remember where in the 5.X series it was introduced.

 

early beta's.

If it doesn't exist, then it's a 4.x or lower version.

Joe, I believe my post above was incorrectly moved when you relocated the posts about the powerdown script.

 

-Paul

It first mentioned the "Safe Mode" so I grouped it here as the next post referenced your post.  It really fits here well too.

 

It is very well written, and very valid, but probably as off-topic for the 5.X release thread as was our discussion of the powerdown script. 

 

If you wish some of its points back in the release thread, you could copy/paste them there.  I'll not move it again on you. 

Just keep the comments pertinent to the "unRAID Server Release 5.0-rc13 being made Available"  and not the fact that there is an API that is barely defined.

I moved your post back into the rc-13 announcement thread.

 

Thank you Joe.

 

-Paul

It was well written. It wasn't censored. It's worthy of discussion.

Possibly in it's own post about the root or core issue being discussed.

 

I don't think the intention was to censor, more so to keep the originating core discussion pertaining to RC13.  Joe suggest you could copy and paste the core message into the thread and he would not move it again.

UnMenu plugins hide under the umbrella of UnMenu, and they benefit from the reputation of UnMenu. For unexperienced users, UnMenu's reputation is good enough to consider every such plugin "legit".  Therefore, the authour of UnMenu should probably design some scheme that clearly displays which plugins are "officially" endorsed by UnMenu, and which plugins -- although they may run on UnMenu -- are not.

 

Edit: This thread was probably not the right place to post this. Sorry.

That is relatively easy.  Most of those in the package manager (downloaded from code.google.com/unraid-unmenu ) I've either authored myself, or at least reviewed the work of the author.    The "about" line will give you a clue who authored what, or at least was the original author.    The bigger issue is compatibility across many versions of unRAID.  What might have been compatible with unRAID 4.4 might have a better solution in unRAID 5.0, or worse, break something.   

 

This in fact happened recently with the unRAID-web package put together by bubbaQ.  It installed a web-server and with it some shared libraries that broke 5.0's ability to partition disks.  It has worked perfectly up until recently.  All I can now do is put a warning on that package that it was not compatible with the newer release of unRAID.

 

As I'm informed of an issue, I correct unMENU in the best way I know as that time.  I specifically consider that a given package might be installed on any version of unRAID.  unMENU's strength is its wide base of users and my quick incorporation of suggestions and contributions.

 

unMENU was originally created to investigate an alternative interface to unRAID.  Because of it, we now have a plugin system in unRAID 5.0.  (In fact, the "plugin" syntax in 5.0 is mostly just an "xml" version of the unMENU .conf file format I used for unMENU packages)

 

Nothing will work forever..., but since unMENU mostly uses scripting languages, it is more adaptable then some other utilities.

so any of you linux guru's going to have a stab at this new script ?

to save energy on my already high power bill i power down every night one of my servers with cron

so a new working script would be welcome

I am more confused than ever with the whole script powerdown issue.  I have been only ever using a v5 beta or rc of some sort and I have the apc plugin (not through umenu package) installed.  Now as far as I am aware it has always worked as expected, taken my server down cleanly with no requirement for a parity check on powering back up.  Now in the RC13 thread there came to light an issue with cleanly taking unraid offline/down.  I lost the plot with all the stock not stock plugin no plugins it's a script issue it's not a script issue then it was said issue was found with the RC13 that was causing the offline problem.  Now RC14 was release with specific fixes for not being able to shutdown cleanly.  It was also raised somewhere along the line the need for a new showtdown script (clean powerdown or what you would like to call it) So for my small brain to understand can someone please fill me in.

 

Was the whole shutdown issue just a problem introduced with RC13 and is now fixed in RC14??

Does the script supplied with the apc plugin still work with RC14 as expected??

Does the powerdown script work with my RC10 and the apc plugin that I run or am I playing Russian roulette??

 

 

 

I am more confused than ever with the whole script powerdown issue.  I have been only ever using a v5 beta or rc of some sort and I have the apc plugin (not through umenu package) installed.  Now as far as I am aware it has always worked as expected, taken my server down cleanly with no requirement for a parity check on powering back up.  Now in the RC13 thread there came to light an issue with cleanly taking unraid offline/down.  I lost the plot with all the stock not stock plugin no plugins it's a script issue it's not a script issue then it was said issue was found with the RC13 that was causing the offline problem.  Now RC14 was release with specific fixes for not being able to shutdown cleanly.  It was also raised somewhere along the line the need for a new showtdown script (clean powerdown or what you would like to call it) So for my small brain to understand can someone please fill me in.

 

Was the whole shutdown issue just a problem introduced with RC13 and is now fixed in RC14??

Does the script supplied with the apc plugin still work with RC14 as expected??

Does the powerdown script work with my RC10 and the apc plugin that I run or am I playing Russian roulette??

 

I second the question.

If I upgrade to RC14 (from RC12a) and have simplefeatures and the APC plugin installed do I need a new powerdown script?

I second the question.

If I upgrade to RC14 (from RC12a) and have simplefeatures and the APC plugin installed do I need a new powerdown script?

 

I have just done this gone from 12a to 14 and have SF and APC plugin installed along with the Serviio and transmission plugins and i was able to shut down and restart with out any issues, tried it a few times to be sure.

I second the question.

If I upgrade to RC14 (from RC12a) and have simplefeatures and the APC plugin installed do I need a new powerdown script?

 

I have just done this gone from 12a to 14 and have SF and APC plugin installed along with the Serviio and transmission plugins and i was able to shut down and restart with out any issues, tried it a few times to be sure.

 

But have you let apc do the shutdown

Was the whole shutdown issue just a problem introduced with RC13 and is now fixed in RC14??

Does the script supplied with the apc plugin still work with RC14 as expected??

Does the powerdown script work with my RC10 and the apc plugin that I run or am I playing Russian roulette??

The RC13 shutdown issue was a problem due to the version of the Linux kernel used and not specific to unRAID.  RC14 has reverted to an earlier Linux kernel until the Linux kernel developers can fix the Linux problem.  Such a fixed kernel is unlikely to be available until after unRAID 5.0 has gone final.

 

This brought to the fore the fact that there is no official way to close down an unRAID system when the GUI stops responding.