dlandon Posted February 10, 2014 Author Share Posted February 10, 2014 Is anyone working with VMs and powerdown? I'd be interested to know if anyone has it working, or is having any issues. I'd like to get this sorted out if there is indeed a problem. EDIT: I just got a VM going and used powerdown to shut down with the VM while running and it shut down just fine on my test system. If anyone else has had any experience with a VM and powerdown, I'd appreciate the feedback. Quote Link to comment
optiman Posted February 11, 2014 Share Posted February 11, 2014 updated to 2.03 and because I use the apc plugin, I removed the lines as instructed. more testing.... I share the apc plugin, if anyone wants it. I figure we are all using the same one, and each of us has to edit each time we change to use the new version of the powerdown script. Apcupsd-3.14.10-i486-4_rlw-dl.fixed_powerdown203.plg.txt Quote Link to comment
optiman Posted February 11, 2014 Share Posted February 11, 2014 Ok, did a webgui STop and then Reboot, upon the boot up, I saw the following line, which I think is related to my flash drive not being unmounted correctly. Feb 10 19:48:14 Tower kernel: FAT-fs (sdg1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. I also noticed that during the shutdown, I did not see the part where it checks each drive, and says PASSED... The shutdown was much quicker, making me think it is skipping something. So when I use the webgui to reboot, does it call the Powerdown script? I did not have this issue before editing the APC plugin and then upgrading to the new powerdown script. Quote Link to comment
PeterB Posted February 11, 2014 Share Posted February 11, 2014 I've just done a reboot from the emhttp interface, running powerdown v2.02 (in order to clean-install v2.03). The log file is very sparse. I don't know whether it is to do with the 'Cannot stat' errors. Feb 11 12:15:39 Tower emhttp: shcmd (153): /sbin/reboot Feb 11 12:15:39 Tower shutdown[10906]: shutting down for system reboot Feb 11 12:15:39 Tower init: Switching to runlevel: 6 Feb 11 12:15:41 Tower rc.unRAID[10915][10916]: Powerdown V2.02 Feb 11 12:15:41 Tower rc.unRAID[10915][10917]: Stopping Plugins. Feb 11 12:15:41 Tower rc.unRAID[10915][10925]: Running: "/etc/rc.d/rc.cache_dirs stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10930]: Running: "/etc/rc.d/rc.couchpotato_v2 stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10941]: Running: "/etc/rc.d/rc.dnsmasq stop" Feb 11 12:15:41 Tower dnsmasq[7270]: exiting on receipt of SIGTERM Feb 11 12:15:41 Tower rc.unRAID[10915][10944]: Running: "/etc/rc.d/rc.dovecot stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10946]: Running: "/etc/rc.d/rc.fan_speed stop" Feb 11 12:15:41 Tower rc.fan_speed: WARNING: fan_speed called to stop with SERVICE not = disabled Feb 11 12:15:41 Tower rc.unRAID[10915][10955]: Running: "/etc/rc.d/rc.logitechmediaserver stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10957]: Running: "/etc/rc.d/rc.minidlna stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10959]: Running: "/etc/rc.d/rc.mpop stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10961]: Running: "/etc/rc.d/rc.mysql stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10967]: Running: "/etc/rc.d/rc.mysqld stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10974]: Running: "/etc/rc.d/rc.transmission stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10976]: Stopping unRAID. Feb 11 12:15:42 Tower rc.unRAID[10915][10996]: No active PIDS on the array Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/disk*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/disk*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/cache: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/cache: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/user*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/user*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /dev/md*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /dev/md*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11003]: Umounting the drives Feb 11 12:15:42 Tower rc.unRAID[10915][11007]: umount: /mnt/disk*: not found Feb 11 12:15:42 Tower rc.unRAID[10915][11007]: Could not find /mnt/disk* in mtab Feb 11 12:15:43 Tower rc.unRAID[10915][11009]: Stopping the Array Feb 11 12:15:43 Tower kernel: mdcmd (7): stop Feb 11 12:15:43 Tower kernel: md: stop_array: not started It seems, to me, that a lot of the working features in v1.02 have been disturbed by the changes introduced in this recent development. Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 Ok, did a webgui STop and then Reboot, upon the boot up, I saw the following line, which I think is related to my flash drive not being unmounted correctly. Feb 10 19:48:14 Tower kernel: FAT-fs (sdg1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. I don't see that on my test system. If you put your flash drive into a Windows system, you should do a safe eject. I also noticed that during the shutdown, I did not see the part where it checks each drive, and says PASSED... The shutdown was much quicker, making me think it is skipping something. The older version of powerdown put a lot of diagnostic information in the log. This has little or no value and clogs the log with messages making it hard to diagnose issues. It has been removed in the newer version. So when I use the webgui to reboot, does it call the Powerdown script? I did not have this issue before editing the APC plugin and then upgrading to the new powerdown script. It's always done that. Powerdown links into the normal unRAID shutdown. You probably didn't notice it before. Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 I've just done a reboot from the emhttp interface, running powerdown v2.02 (in order to clean-install v2.03). The log file is very sparse. I don't know whether it is to do with the 'Cannot stat' errors. The older version of powerdown put a lot of diagnostic information in the log. This has little or no value and clogs the log with messages making it hard to diagnose issues. It has been removed in the newer version. The 'Cannot stat' errors are from rc.unRAID doing its job. That's just a normal part of the process. Feb 11 12:15:39 Tower emhttp: shcmd (153): /sbin/reboot Feb 11 12:15:39 Tower shutdown[10906]: shutting down for system reboot Feb 11 12:15:39 Tower init: Switching to runlevel: 6 Feb 11 12:15:41 Tower rc.unRAID[10915][10916]: Powerdown V2.02 Feb 11 12:15:41 Tower rc.unRAID[10915][10917]: Stopping Plugins. Feb 11 12:15:41 Tower rc.unRAID[10915][10925]: Running: "/etc/rc.d/rc.cache_dirs stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10930]: Running: "/etc/rc.d/rc.couchpotato_v2 stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10941]: Running: "/etc/rc.d/rc.dnsmasq stop" Feb 11 12:15:41 Tower dnsmasq[7270]: exiting on receipt of SIGTERM Feb 11 12:15:41 Tower rc.unRAID[10915][10944]: Running: "/etc/rc.d/rc.dovecot stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10946]: Running: "/etc/rc.d/rc.fan_speed stop" Feb 11 12:15:41 Tower rc.fan_speed: WARNING: fan_speed called to stop with SERVICE not = disabled Feb 11 12:15:41 Tower rc.unRAID[10915][10955]: Running: "/etc/rc.d/rc.logitechmediaserver stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10957]: Running: "/etc/rc.d/rc.minidlna stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10959]: Running: "/etc/rc.d/rc.mpop stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10961]: Running: "/etc/rc.d/rc.mysql stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10967]: Running: "/etc/rc.d/rc.mysqld stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10974]: Running: "/etc/rc.d/rc.transmission stop" Feb 11 12:15:41 Tower rc.unRAID[10915][10976]: Stopping unRAID. Feb 11 12:15:42 Tower rc.unRAID[10915][10996]: No active PIDS on the array Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/disk*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/disk*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/cache: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/cache: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/user*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /mnt/user*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /dev/md*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11002]: Cannot stat /dev/md*: No such file or directory Feb 11 12:15:42 Tower rc.unRAID[10915][11003]: Umounting the drives Feb 11 12:15:42 Tower rc.unRAID[10915][11007]: umount: /mnt/disk*: not found Feb 11 12:15:42 Tower rc.unRAID[10915][11007]: Could not find /mnt/disk* in mtab Feb 11 12:15:43 Tower rc.unRAID[10915][11009]: Stopping the Array Feb 11 12:15:43 Tower kernel: mdcmd (7): stop Feb 11 12:15:43 Tower kernel: md: stop_array: not started It seems, to me, that a lot of the working features in v1.02 have been disturbed by the changes introduced in this recent development. Everything looks good in your log. What you are not seeing are all the smart reports and diagnostics that are not going to the log now so it appears that it might be skipping something, but it isn't. Quote Link to comment
PeterB Posted February 11, 2014 Share Posted February 11, 2014 Everything looks good in your log. What you are not seeing are all the smart reports and diagnostics that are not going to the log now so it appears that it might be skipping something, but it isn't. Okay, so you're saying that you've deliberately removed a lot of the information having judged that it is not useful? I would have thought that much of the removed information could have been useful in some circumstances - for instance, a drive error occurring in one session could be confirmed by changes in smart information between two consecutive sessions. On the other hand, I was aware that shutdowns were taking longer than was absolutely necessary, which could be critical in the case of a power failure. Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 Everything looks good in your log. What you are not seeing are all the smart reports and diagnostics that are not going to the log now so it appears that it might be skipping something, but it isn't. Okay, so you're saying that you've deliberately removed a lot of the information having judged that it is not useful? I would have thought that much of the removed information could have been useful in some circumstances - for instance, a drive error occurring in one session could be confirmed by changes in smart information between two consecutive sessions. On the other hand, I was aware that shutdowns were taking longer than was absolutely necessary, which could be critical in the case of a power failure. The information could be useful, but there are other ways to get it. You can still get that diagnostic information in the log using the following: /etc/rc.d/rc.unRAID diag This will put the information in the log that used to be there. It takes time to gather all that smart information from the drives. Quote Link to comment
MrLondon Posted February 11, 2014 Share Posted February 11, 2014 I installed version 2.03 it said it was successful but under /etc it didn't create a new file and when I type powerdown it just hangs till I do control+c Sent from my iPhone using Tapatalk Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 I installed version 2.03 it said it was successful but under /etc it didn't create a new file and when I type powerdown it just hangs till I do control+c Sent from my iPhone using Tapatalk Syslog please. Quote Link to comment
PeterB Posted February 11, 2014 Share Posted February 11, 2014 The information could be useful, but there are other ways to get it. You can still get that diagnostic information in the log using the following: /etc/rc.d/rc.unRAID diag Ah, so this will give us the old, verbose, diagnostics in the log? This will put the information in the log that used to be there. Okay, but it cannot work in retrospect - we would always have to run in diag mode. It takes time to gather all that smart information from the drives. Of course. Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 The information could be useful, but there are other ways to get it. You can still get that diagnostic information in the log using the following: /etc/rc.d/rc.unRAID diag Ah, so this will give us the old, verbose, diagnostics in the log? This will put the information in the log that used to be there. Okay, but it cannot work in retrospect - we would always have to run in diag mode. It takes time to gather all that smart information from the drives. Of course. /etc/rc.d/rc.unRAID diag is the same information that used to be in the log on every shutdown. There is no "diag" mode per-se. Quote Link to comment
optiman Posted February 11, 2014 Share Posted February 11, 2014 Thanks dlandon! I didn't realize that info was now removed on purpose. Also, I did remove my flash drive, put into my Win7 box and did a check. It did have errors that it corrected, so it is now fixed. My guess is that it was writing to the log file the other day when I had to force the shutdown due to SABnzbd hanging on me. I did notice a new file in the /boot/config/ directory "secrets.tdb" Do you happen to know what this is? This file was not on my flash drive before. A gui stop and poweroff worked fine, no errors. Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 Thanks dlandon! I didn't realize that info was now removed on purpose. Also, I did remove my flash drive, put into my Win7 box and did a check. It did have errors that it corrected, so it is now fixed. My guess is that it was writing to the log file the other day when I had to force the shutdown due to SABnzbd hanging on me. I did notice a new file in the /boot/config/ directory "secrets.tdb" Do you happen to know what this is? This file was not on my flash drive before. A gui stop and poweroff worked fine, no errors. That's an unRAID file - not sure what it does. The reason I started on this journey to update powerdown (my head hurts - the learning curve has been horrendous! WeeboTech has been a huge help.) was because powerdown 1.02 was locking up on me and when I had to push the power button I got the "secrets.db" corrupted file on the next boot and unRAID would not start. It was not pretty! I had to take the flash to a Windows computer to correct the errors and all was well again. Powerdown should now be able to handle shutdowns without this problem. Quote Link to comment
peter_sm Posted February 11, 2014 Share Posted February 11, 2014 I have edit my APC plugin, when install it I got this messages, I also see same "warning" when I run Smart History in UnMenu. I do not see this is V5, only in V6 I have set my timezone in the unraid settings. Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/emhttp/plugins/apcupsd/apcupsdctl.php on line 76 ?? Quote Link to comment
dlandon Posted February 11, 2014 Author Share Posted February 11, 2014 I have edit my APC plugin, when install it I got this messages, I also see same "warning" when I run Smart History in UnMenu. I do not see this is V5, only in V6 I have set my timezone in the unraid settings. Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/emhttp/plugins/apcupsd/apcupsdctl.php on line 76 ?? That's in the apcupsd plugin. I don't know anything about that. I just ignore it on my system. Quote Link to comment
phenomeus Posted February 11, 2014 Share Posted February 11, 2014 i intalled powerdown 2.0.3 on my HP40L with unraid 5.0.5. before that, i had a working auto_s3_sleep.sh from jens combined with Clean Powerdown from unMenu. (http://s3.jens-thiel.de/HP/auto_s3_sleep.sh.txt) i have to use the option "powerDownInsteadOfSleep=$yes" because my server can't use "echo 3 > /proc/acpi/sleep" or the new one: "echo -n mem > /sys/power/state" but with powerdown 2.0.3 i can't wake my server with WOL. it's like the server is going in such a deep power off, that it can't work with magic packets anymore. only the powerbutton works, but that's not an option when i'm out of home. so please, could you help me get it back working? thanks in advance. Quote Link to comment
dlandon Posted February 12, 2014 Author Share Posted February 12, 2014 i intalled powerdown 2.0.3 on my HP40L with unraid 5.0.5. before that, i had a working auto_s3_sleep.sh from jens combined with Clean Powerdown from unMenu. (http://s3.jens-thiel.de/HP/auto_s3_sleep.sh.txt) i have to use the option "powerDownInsteadOfSleep=$yes" because my server can't use "echo 3 > /proc/acpi/sleep" or the new one: "echo -n mem > /sys/power/state" but with powerdown 2.0.3 i can't wake my server with WOL. it's like the server is going in such a deep power off, that it can't work with magic packets anymore. only the powerbutton works, but that's not an option when i'm out of home. so please, could you help me get it back working? thanks in advance. Send me a log so I can take a look. Quote Link to comment
optiman Posted February 12, 2014 Share Posted February 12, 2014 I have edit my APC plugin, when install it I got this messages, I also see same "warning" when I run Smart History in UnMenu. I do not see this is V5, only in V6 I have set my timezone in the unraid settings. Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/emhttp/plugins/apcupsd/apcupsdctl.php on line 76 ?? I just checked my log and I do not see that error message, although I have seen in the past. I think I saw this when I was using the new webgui or maybe it was SF. I'm now running stock gui and do not have that error. You can compare my plugin file with yours, I posted it on the last page. Perhaps there is a difference. Or the difference could be in the cfg file. I'm happy to share any files you may want to compare. Quote Link to comment
PeterB Posted February 12, 2014 Share Posted February 12, 2014 I have edit my APC plugin, when install it I got this messages, I also see same "warning" when I run Smart History in UnMenu. I do not see this is V5, only in V6 I have set my timezone in the unraid settings. Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/emhttp/plugins/apcupsd/apcupsdctl.php on line 76 ?? I just checked my log and I do not see that error message, although I have seen in the past. I think I saw this when I was using the new webgui or maybe it was SF. I'm now running stock gui and do not have that error. You can compare my plugin file with yours, I posted it on the last page. Perhaps there is a difference. Or the difference could be in the cfg file. I'm happy to share any files you may want to compare. I'm the person responsible for the 64bit conversion of the apcupsd plugin. I do not get this error on my system. Can you tell me exactly what it says on your Date and Time settings page in emhttp ... particularly what appears on the "Current date & time:" line. Quote Link to comment
optiman Posted February 12, 2014 Share Posted February 12, 2014 attached is a screenshot of my Settings --> Date and Time page in the stock gui. I hope that is what you meant. If not, let me know. Quote Link to comment
PeterB Posted February 12, 2014 Share Posted February 12, 2014 I have edit my APC plugin, when install it I got this messages, I also see same "warning" when I run Smart History in UnMenu. I do not see this is V5, only in V6 I have set my timezone in the unraid settings. Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/emhttp/plugins/apcupsd/apcupsdctl.php on line 76 ?? I just checked my log and I do not see that error message, although I have seen in the past. I think I saw this when I was using the new webgui or maybe it was SF. I'm now running stock gui and do not have that error. You can compare my plugin file with yours, I posted it on the last page. Perhaps there is a difference. Or the difference could be in the cfg file. I'm happy to share any files you may want to compare. I'm the person responsible for the 64bit conversion of the apcupsd plugin. I do not get this error on my system. Can you tell me exactly what it says on your Date and Time settings page in emhttp ... particularly what appears on the "Current date & time:" line. Okay, I was too quick to post - sorry. I can confirm that I do see this message in the logfile, but only on V6. I would also report that Powerdown appears to block a reboot (either from the command line or from the emhttp interface) in V6. After initiating the reboot, there is some output to the console, but the last thing which appears is the text 'Powerdown v2.03', and no further activity occurs. EDIT: I've just reverted to Powerdown 1.02 with v6 - the timezone error is still reported - I'm guessing that there is some problem with the php date() function in V6. I can also confirm that reboot works perfectly well from the command line with Powerdown 1.02 running unRAID v6. Quote Link to comment
Freddie Posted February 12, 2014 Share Posted February 12, 2014 I've been testing powerdown V2.03 on unRAID 6.0-beta3 and it seems to work quite well. I installed the powerdown plugin from the first post and I do not have apcupsd. I tested with and without Xen enabled at boot. I also tested with and without a VM running. I noticed the custom Kxx scripts are executed in reverse order: K99 is first and K00 is last. My custom vm shutdown script is quite simple: [ -f /var/run/xenstored.pid ] && xl shutdown -a sleep 20 If you only use: xl shutdown -a the powerdown will continue while the VMs are shutting down and xen processes could get killed before the VM shutdowns are complete. i intalled powerdown 2.0.3 on my HP40L with unraid 5.0.5. ... but with powerdown 2.0.3 i can't wake my server with WOL. I did many powerdown cycles on my HP N40L today and WOL worked just fine. Quote Link to comment
peter_sm Posted February 12, 2014 Share Posted February 12, 2014 attached is a screenshot of my Settings --> Date and Time page in the stock gui. I hope that is what you meant. If not, let me know. Yes, that is the settings, And I have timezone set for Sweden, but I could try with your timezon to see if it this messages are gone? Cant try it right now, can do it in the weekend, but if you do not see this, then I shall try to change to the timezone you use ;-) and see if it's OK for me as well. But We might need Tom take a look at this! I have posted the issue in V6 beta3 thread, it must be something broken for php and Timezone @PeterB Can you try to change timezone ( UTS +1) and see what happens! I'm running with No plugins, except UPS, and stock GUI //Peter //Peter Quote Link to comment
dlandon Posted February 12, 2014 Author Share Posted February 12, 2014 I have edit my APC plugin, when install it I got this messages, I also see same "warning" when I run Smart History in UnMenu. I do not see this is V5, only in V6 I have set my timezone in the unraid settings. Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/local/emhttp/plugins/apcupsd/apcupsdctl.php on line 76 ?? I just checked my log and I do not see that error message, although I have seen in the past. I think I saw this when I was using the new webgui or maybe it was SF. I'm now running stock gui and do not have that error. You can compare my plugin file with yours, I posted it on the last page. Perhaps there is a difference. Or the difference could be in the cfg file. I'm happy to share any files you may want to compare. I'm the person responsible for the 64bit conversion of the apcupsd plugin. I do not get this error on my system. Can you tell me exactly what it says on your Date and Time settings page in emhttp ... particularly what appears on the "Current date & time:" line. Okay, I was too quick to post - sorry. I can confirm that I do see this message in the logfile, but only on V6. I would also report that Powerdown appears to block a reboot (either from the command line or from the emhttp interface) in V6. After initiating the reboot, there is some output to the console, but the last thing which appears is the text 'Powerdown v2.03', and no further activity occurs. EDIT: I've just reverted to Powerdown 1.02 with v6 - the timezone error is still reported - I'm guessing that there is some problem with the php date() function in V6. I can also confirm that reboot works perfectly well from the command line with Powerdown 1.02 running unRAID v6. Start a telnet session and execute this command: tail -n 10 -f /var/log/syslog Do a powerdown or webgui reboot and report back the results. 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.