Squid Posted August 20, 2016 Author Share Posted August 20, 2016 I got a warning last night telling me my server's time is out by approximately 40 minutes. It looks fine to me and the time hasn't changed. Just ignore it. I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results. I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed. Quote Link to comment
RobJ Posted August 21, 2016 Share Posted August 21, 2016 I got a warning last night telling me my server's time is out by approximately 40 minutes. It looks fine to me and the time hasn't changed. Just ignore it. I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results. I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed. Another example, with a little more detail: Aug 11 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06 Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored Aug 11 04:40:07 JacoBack logger: Fix Common Problems: Other Warning: Disk(s) disk1 disk10 disk11 disk2 disk3 disk4 disk5 disk6 disk7 disk8 disk9 are spun down. Skipping write check and HPA check Aug 11 04:40:08 JacoBack logger: Community Applications Auto Update Running ... Aug 12 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06 Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored Aug 12 04:40:06 JacoBack logger: Fix Common Problems: Warning: Your server's current time differs from the actual time by more than 5 minutes. Currently out by approximately 308 minutes Aug 12 04:40:08 JacoBack logger: Fix Common Problems: Other Warning: Disk(s) disk1 disk10 disk11 disk2 disk3 disk4 disk5 disk6 disk7 disk8 disk9 are spun down. Skipping write check and HPA check Aug 12 04:40:12 JacoBack logger: Community Applications Auto Update Running Aug 12 09:47:10 JacoBack emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall No problem on Aug 11, claims clock off by 5 hours 8 minutes (so not a timezone issue) on Aug 12. Noticed this message about 9:30am, did a plugin check at 9:47am just to put a timestamp into log, and it was perfect. No apparent clock corrections, just a check against the wrong time (under some condition, randomly generated?). (still on 6.1.9) Quote Link to comment
Squid Posted August 21, 2016 Author Share Posted August 21, 2016 I got a warning last night telling me my server's time is out by approximately 40 minutes. It looks fine to me and the time hasn't changed. Just ignore it. I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results. I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed. Another example, with a little more detail: Aug 11 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06 Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored Aug 11 04:40:07 JacoBack logger: Fix Common Problems: Other Warning: Disk(s) disk1 disk10 disk11 disk2 disk3 disk4 disk5 disk6 disk7 disk8 disk9 are spun down. Skipping write check and HPA check Aug 11 04:40:08 JacoBack logger: Community Applications Auto Update Running ... Aug 12 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06 Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored Aug 12 04:40:06 JacoBack logger: Fix Common Problems: Warning: Your server's current time differs from the actual time by more than 5 minutes. Currently out by approximately 308 minutes Aug 12 04:40:08 JacoBack logger: Fix Common Problems: Other Warning: Disk(s) disk1 disk10 disk11 disk2 disk3 disk4 disk5 disk6 disk7 disk8 disk9 are spun down. Skipping write check and HPA check Aug 12 04:40:12 JacoBack logger: Community Applications Auto Update Running Aug 12 09:47:10 JacoBack emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall No problem on Aug 11, claims clock off by 5 hours 8 minutes (so not a timezone issue) on Aug 12. Noticed this message about 9:30am, did a plugin check at 9:47am just to put a timestamp into log, and it was perfect. No apparent clock corrections, just a check against the wrong time (under some condition, randomly generated?). (still on 6.1.9) It's never going to be a time zone issue as I'm comparing Unix epoch times. But rather its an issue on the time server's end. I'll look around for another server that suits my needs or modify the code to issue it as an other warning or something. Sent from my LG-D852 using Tapatalk Quote Link to comment
gsd2012 Posted August 25, 2016 Share Posted August 25, 2016 Squid, I looked to see if this was covered in the postings some where but I am did not find it. Are these a false positive or something I need to really look at? They are under "other comments" so I was not sure before ignoring them. Could not perform unknown plugins installed checks The download of the application feed failed. Could not perform docker application port tests The download of the application feed failed. Thanks for a great plugin! Greg Quote Link to comment
Squid Posted August 26, 2016 Author Share Posted August 26, 2016 Squid, I looked to see if this was covered in the postings some where but I am did not find it. Are these a false positive or something I need to really look at? They are under "other comments" so I was not sure before ignoring them. Could not perform unknown plugins installed checks The download of the application feed failed. Could not perform docker application port tests The download of the application feed failed. Thanks for a great plugin! Greg Its exactly what it says. FCP was unable to download an application feed (the same feed which CA uses), so it couldn't perform those tests. Usually in conjunction with this there are also errors about connectivity, but occasionally there are not (due to various other factors such as your VPN provider blocking cloudfare, etc) Quote Link to comment
Hoopster Posted September 5, 2016 Share Posted September 5, 2016 I have a problem with Fix Common Problems. Any time the plugin is opened, its spins up all the discs and starts scanning. This scanning message "hangs' (i.e the scanning message never goes away even after hours) the WebGUI and it is unavailable unless I close it and reopen it in a different browser tab. Am I just being impatient? Should it take several hours checking permissions? I do have over 120,000 photos and videos stored on the server. I cannot configure the plugin as it immediately starts scanning whenever opened and never finishes. As you can see, I am running unRAID 6.1.9 and the version of FCP is the latest (2016.09.04) although this has been happening for at least a month before it was updated today to the latest. Diagnostics attached in case it is helpful. See screenshot: medianas-diagnostics-20160905-1101.zip Quote Link to comment
Squid Posted September 5, 2016 Author Share Posted September 5, 2016 Works fine for me. What browser are you using? Sent from my LG-D852 using Tapatalk Quote Link to comment
Hoopster Posted September 5, 2016 Share Posted September 5, 2016 Works fine for me. What browser are you using? Sent from my LG-D852 using Tapatalk Firefox 48.0.2 Just tried it on Chrome, same thing. Tried it on Edge, same thing. Of course, I did not let FCP run for hours, but, in all browsers, it starts scanning immediately when started and I cannot configure the plugin as it "hangs" on scanning. I just attached diagnostics to original post if helpful. This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10. I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that stated around the time of the upgrade as well. Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install. I doubt this has anything to do with it, but, just to eliminate a variable, I will try it. Quote Link to comment
Hoopster Posted September 5, 2016 Share Posted September 5, 2016 Works fine for me. What browser are you using? Sent from my LG-D852 using Tapatalk This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10. I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well. Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install. I doubt this has anything to do with it, but, just to eliminate a variable, I will try it. Well, what do you know? It appears that is, in fact, the root of the problem. On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs. Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause. No errors or warnings were found with the FCP scan from my laptop, so, that is also good news Quote Link to comment
Squid Posted September 5, 2016 Author Share Posted September 5, 2016 Works fine for me. What browser are you using? Sent from my LG-D852 using Tapatalk This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10. I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well. Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install. I doubt this has anything to do with it, but, just to eliminate a variable, I will try it. Well, what do you know? It appears that is, in fact, the root of the problem. On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs. Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause. No errors or warnings were found with the FCP scan from my laptop, so, that is also good news It may infact be a bug. While I can't recreate it your behaviour, I would hazard a guess that your desktop has adblockers installed, while the laptop does not. FCP throws up a popup if an adblocker is detected, but if its never been run before on top of that it throws up the Scanning popup. On mine under those circumstances, both the popups wind up being closed at the conclusion of the scan, but for some reason yours might be different (no idea why). I'll rearrange the order of the tests. Quote Link to comment
Hoopster Posted September 5, 2016 Share Posted September 5, 2016 Works fine for me. What browser are you using? Sent from my LG-D852 using Tapatalk This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10. I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well. Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install. I doubt this has anything to do with it, but, just to eliminate a variable, I will try it. Well, what do you know? It appears that is, in fact, the root of the problem. On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs. Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause. No errors or warnings were found with the FCP scan from my laptop, so, that is also good news It may infact be a bug. While I can't recreate it your behaviour, I would hazard a guess that your desktop has adblockers installed, while the laptop does not. FCP throws up a popup if an adblocker is detected, but if its never been run before on top of that it throws up the Scanning popup. On mine under those circumstances, both the popups wind up being closed at the conclusion of the scan, but for some reason yours might be different (no idea why). I'll rearrange the order of the tests. Hmmm.... interesting theory. I do have Adblock+ installed in Firefox; however, it is installed on both the laptop and the desktop. My successful run of FCP on the laptop was with Firefox with ABP installed and enabled. No popup blockers were manually installed for Chrome or Edge on the desktop and FCP failed in the same way on both of those browsers as well. I also disabled the Edge built in popup blocker and saw the same behavior. I then disabled ABP in Firefox and ran FCP again on the desktop; same result. Quote Link to comment
Squid Posted September 5, 2016 Author Share Posted September 5, 2016 Works fine for me. What browser are you using? Sent from my LG-D852 using Tapatalk This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10. I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well. Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install. I doubt this has anything to do with it, but, just to eliminate a variable, I will try it. Well, what do you know? It appears that is, in fact, the root of the problem. On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs. Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause. No errors or warnings were found with the FCP scan from my laptop, so, that is also good news It may infact be a bug. While I can't recreate it your behaviour, I would hazard a guess that your desktop has adblockers installed, while the laptop does not. FCP throws up a popup if an adblocker is detected, but if its never been run before on top of that it throws up the Scanning popup. On mine under those circumstances, both the popups wind up being closed at the conclusion of the scan, but for some reason yours might be different (no idea why). I'll rearrange the order of the tests. Hmmm.... interesting theory. I do have Adblock+ installed in Firefox; however, it is installed on both the laptop and the desktop. My successful run of FCP on the laptop was with Firefox with ABP installed and enabled. No popup blockers were manually installed for Chrome or Edge on the desktop and FCP failed in the same way on both of those browsers as well. I also disabled the Edge built in popup blocker and saw the same behavior. I then disabled ABP in Firefox and ran FCP again on the desktop; same result. Then I don't have any good answers. I'll still rearrange the order of things being done however. Quote Link to comment
dlandon Posted September 11, 2016 Share Posted September 11, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. Quote Link to comment
Squid Posted September 13, 2016 Author Share Posted September 13, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Quote Link to comment
dlandon Posted September 13, 2016 Share Posted September 13, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. That's a plan. I know some people still want to use it, but it has become increasingly difficult to chase down the changes in the shutdown scheme LT implements in each version and for me to try to keep up. LT has also improved the shutdown in 6.2 and does not rely on emhttp for the shutdown which is where the process would get stuck waiting for something to happen/complete. In 6.1 dockers and VMs were shutdown by the unmounting events. In 6.2 the dockers and VMs are shut down with explicit calls for a shutdown. I've suggested a few changes to the built in shutdown and if they do those, there is not much need at all for the powerdown script. Quote Link to comment
Squid Posted September 14, 2016 Author Share Posted September 14, 2016 - Updated with the downgrade in alert level for powerdown not installed - Fixed a race condition if an ad-blocker was installed, and no errors were found on previous scan (or if first scan after a reboot) by going to an (ugh) old-school style alert for ad-blockers - faster downloads on the application feed (and more checks if its complete) Quote Link to comment
luigi408 Posted September 16, 2016 Share Posted September 16, 2016 Hi, I've been using the beta 6.2 for a while now. Now that I upgraded to 6.2 stable its detecting this problem: docker appdata location is stored within /mnt/user Many (if not most) docker applications will have issues (weird results, not starting, etc) if their appdata is stored within a user share. You should constrain the appdata share to a singledisk or to the cache drive. This is true even if the appdata share is a Cache-Only share. Is this an actual error? Because the location of /mnt/user was done by Unraid automatically. Quote Link to comment
Squid Posted September 16, 2016 Author Share Posted September 16, 2016 Now that 6.2 is final that is going to be deprecated. Updated... With 6.2 dropping the RC-x suffixes, my existing test that was ignoring those tests during the RC stage wound up executing under 6.2 final Sent from my LG-D852 using Tapatalk Quote Link to comment
dlandon Posted September 16, 2016 Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Quote Link to comment
Squid Posted September 16, 2016 Author Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Quote Link to comment
Squid Posted September 16, 2016 Author Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) Quote Link to comment
dlandon Posted September 16, 2016 Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1. Quote Link to comment
Squid Posted September 16, 2016 Author Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1. Should probably change it then Quote Link to comment
dlandon Posted September 16, 2016 Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1. Should probably change it then Done. Set to 6.1.9. As I understand, that is the max version CA will allow and FCP will check. Quote Link to comment
Squid Posted September 16, 2016 Author Share Posted September 16, 2016 The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future. ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1. Should probably change it then Done. Set to 6.1.9. As I understand, that is the max version CA will allow and FCP will check. Correct. And CA is already flagging it as incompatible on my 6.2 system and my 6.1.9 system its ok. Just have to reconfigure FCP and we're good to go. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.