a12vman

Here we go again. I still can't get a handle on why my server is shutting down within seconds of a power loss. UPS Power Level was at 100% before the power loss - the batteries are less than 6 months old. I asked this question before - how do the redundant power supplies work in my server, are both always drawing current? I have both of them plugged into my UPS. This is a Dell server. Unconfirmed but I am reading that Dell splits the load across both PSU's until one fails. Could that be causing my issue? Running on battery for < 90 Seconds going to shutdown takes my battery charge down to 70%?

Ok I got this sorted out. I didn't have the "Share" option toggled. I toggled Share on and waited a few minutes - all good now. I am using this UD as a Download bucket for Sabnzbd/Deluge/Sonarr. I didn't see the point in having this writing into the Array(and/or Cache). Sometimes I pull down large files. For example a 512GB RasPi Image. Any thoughts on this and what are other users doing? I know it's unprotected but it seems like a lot of overkill writing files into the array as they are being downloaded.

Ok I did that and re-mounted the drive. When I try to access that share from Windows I get the "Cannot access share" message. I also tried accessing the share directly(\\mediatower\download) - that didn't work either. I don't understand what my issue is here. I have another UD with a share that I'm able to access(SabNzbd) without any issues.

I retired this 4TB drive from my array and would like to use it as an unassigned device. Is there any way to rename the Top Level Share name? Currently it is HGST_HDN724040ALE640_PK2334PCG5232B It's too cryptic to use right now windows won't even recognize that. I tried using Krusader and doing a rename but it didn't work. Maybe I am missign something obvious. I don't see a way to do this within the Unraid UI or the UD Plugin. I have already formatted the Drive, it is empty.

I stopped the array after the parity sync completed on 14TB in the Parity 2 Slot. I tried: Select "No Device" for Parity 2, Select "No Device" for Parity Select 14TB drive as Parity Result was arrray start button was disabled. Lesson learned. - big waste of time trying to do Parity Sync in Parity 2. I am now doing Parity Sync on 14TB Drive after making 12TB Parity drive as an unassigned Device and then making 14TB drive as one & only Parity Drive. Now I get to wait for another Parity Sync to complete before I can remove & reassign Data Drive 2 to the 12TB Drive.

Is there any downside to doing this? Makes me wonder how many are running with dual parity vs single parity.

I did the parity sync on drive 2 so that I didn't have my array unprotected during the process. I am confident in the parity I have on the 10TB drive. Are you saying that I will have to do this again when 14TB becomes the one and only parity drive?

I have 5/6 Bays in use on my Dell Server: Parity: 12TB Data: 10TB 6TB 6TB 4TB I want to retire the 4TB Drive. I 14TB Drive in Slot 6, it is Pre-cleared and nearly complete with a Parity Sync as Parity Drive 2. When the Parity Sync completes I want to: Pull 4TB drive and replace it with 10TB Parity Drive 1. Make 14TB Parity Drive 2 be Parity Drive 1. Is this the right way to go? When this is complete I want keep 1 Slot open.

I decided to give Duplicati a try as my backup solution. I have been using UnRaid for the last 10 years but I stepped up my game in the last year by setting up several dockers along with a few VM's on my Quad Xeon with 64GB Ram. I installed the Docker and scheduled a 220GB backup from Unraid to a remote SMB Share(Synology Box) for 3am. When I woke up this morning it looks as if the backup was complete(~220GB of duplicati files in my Synology Share). I attampted to access the Duplicati WebUI but it won't come up - stuck on loading. I stopped and re-started the Docker - same result. I stopped the array and re-booted the server - same result I can't access the WebUI. No errors in the Docker Log and no errors in Syslog. Where do I go next?

I hope this is the last time I have to post about my UPS. I adjusted the 3 settings slightly. Left both PSU's pugged into the UPS and have tested multiple times with the breaker shutoff for varying durations. It is switching back and forth without causing a shutdown. Thanks for everyone's suggestions.

Ok I just completed a load test. With nothing else plugged but a Halogen Work Light(confirmed power draw with Kill-A-Watt @ 400w). With the Halogen on and plugged into the UPS I flipped the Breaker Off. It ran on Battery Power for 4:45 seconds before it dropped from 3 Bars down to 2 Bars. Left it run for another 2 minutes with plenty of power to spare and then I turned it off. Clearly my batteries are strong enough to run my server for at least a few minutes so what is my issue? Does anyone know how dell's redundant power supplies work? Is it possible that the UPS is falsely detecting both power supplies drawing power? Should I have only one of the power supplies plugged into the UPS? I am happy that it does a clean power down but the majority of my local power interruptions only last 2-3 minutes so I would expect it to handle that without forcing a power down.

I installed the TrippLite Mgmt software on my laptop. everything looks good from what it is reporting on batteries. My next step is to do a manual load test on these batteries and see if they can deliver.

I set the Runtime Left to Initiate Shutdown to 0 and applied changes. Flipped the breaker off and went right into shutdown again. Aug 8 13:05:33 MediaTower apcupsd[26612]: Power failure. Aug 8 13:05:39 MediaTower apcupsd[26612]: Running on UPS batteries. Aug 8 13:05:50 MediaTower apcupsd[26612]: Battery power exhausted. Aug 8 13:05:50 MediaTower apcupsd[26612]: Initiating system shutdown! Aug 8 13:05:50 MediaTower apcupsd[26612]: User logins prohibited Aug 8 13:05:51 MediaTower root: /usr/local/sbin/powerdown has been deprecated Aug 8 13:05:51 MediaTower init: Switching to runlevel: 0 Aug 8 13:05:51 MediaTower init: Trying to re-exec init I guess I move on to a basic load test to make sure these batteries are good.

Ok I am sad to say that I am still haveing issues with my UPS and it is really frustrating. After replacing the batteries in my TrippLite SMC-1500T and re-configuring the parameters in UPS Settings I am still having a shutdown initiated within a few seconds of switching to battery power. Here is is part of the log: Aug 7 19:32:18 MediaTower apcupsd[1832]: Power failure. Aug 7 19:32:23 MediaTower apcupsd[1832]: Running on UPS batteries. Aug 7 19:32:33 MediaTower apcupsd[1832]: Battery power exhausted. Aug 7 19:32:33 MediaTower apcupsd[1832]: Initiating system shutdown! Aug 7 19:32:33 MediaTower apcupsd[1832]: User logins prohibited Aug 7 19:32:33 MediaTower apcupsd[1832]: Mains returned. No longer on UPS batteries. Aug 7 19:32:33 MediaTower apcupsd[1832]: Power is back. UPS running on mains. Aug 7 19:32:33 MediaTower apcupsd[1832]: Allowing logins Aug 7 19:32:33 MediaTower root: /usr/local/sbin/powerdown has been deprecated A couple weeks ago we had an actual power failure and this log shows it ran on battery for ~ 12 minutes before shutdown. Jul 27 11:20:25 MediaTower apcupsd[6650]: Running on UPS batteries. Jul 27 11:32:45 MediaTower apcupsd[6650]: Battery power exhausted. Jul 27 11:32:45 MediaTower apcupsd[6650]: Initiating system shutdown! I don't have anything else plugged into my UPS. This is a Dell server with Dual Power Supplies(both are plugged into the TrippLite). It shows a 38 Minute run time with a 23% Load. Here are my ups parameters: I ran the self test as TrippLite suggests holding the mute button. It switched over to battery power for a short time, let out a few beeps and was complete. Battery charge dropped from 100% to 90% in that 30 second period as reported by unraid. Why is it still randomly going into immediate shutdown instead of using the available battery capacity?

Entered legit values for Runtime Left and Time On Battery. Cut the power at the breaker, this time no immediate shutdown. I let the server run for 10 minutes on battery power then flipped the breaker back on. I now have a new set of batteries which I probably needed anyways so I think we can consider this resolved. Thanks for everyone's help!

I powered down the server and installed 3 new 12.7ah batteries into the UPS. Powered up the UPS and ran a self-test/diagnostic. Powered my server back up. Brought the server back to normal load with dockers/VM's running. Shut off the breaker to the UPS. Again same issue - Server powers down within a minute of turning off the breaker. If I understand the config it should keep running on batteries until it drops to 60%. What is the issue?

I am ordering a new set of batteries. I will do a plugs-out test while the array is offline once I get the new batteries and they are fully charged.

I could really use some help here. Same issue again this afternoon, here are the bits from SysLog.txt: Jul 7 15:59:28 MediaTower apcupsd[14039]: Power failure. Jul 7 15:59:33 MediaTower apcupsd[14039]: Reached remaining time percentage limit on batteries. Jul 7 15:59:33 MediaTower apcupsd[14039]: Initiating system shutdown! Jul 7 15:59:33 MediaTower apcupsd[14039]: User logins prohibited Jul 7 15:59:33 MediaTower root: /usr/local/sbin/powerdown has been deprecated Jul 7 15:59:33 MediaTower init: Switching to runlevel: 0 Jul 7 15:59:33 MediaTower apcupsd[14039]: Power is back. UPS running on mains. Jul 7 15:59:33 MediaTower apcupsd[14039]: Allowing logins Jul 7 15:59:33 MediaTower init: Trying to re-exec init Jul 7 15:59:34 MediaTower nginx: 2020/07/07 15:59:34 [alert] 9175#9175: *3908688 open socket #26 left in connection 9 Jul 7 15:59:34 MediaTower nginx: 2020/07/07 15:59:34 [alert] 9175#9175: *3908686 open socket #19 left in connection 15 Jul 7 15:59:34 MediaTower nginx: 2020/07/07 15:59:34 [alert] 9175#9175: aborting Jul 7 15:59:37 MediaTower kernel: mdcmd (46): nocheck cancel Jul 7 15:59:38 MediaTower emhttpd: Spinning up all drives... Jul 7 15:59:38 MediaTower emhttpd: shcmd (60463): /usr/sbin/hdparm -S0 /dev/sdi Jul 7 15:59:38 MediaTower kernel: mdcmd (47): spinup 0 Jul 7 15:59:38 MediaTower kernel: mdcmd (48): spinup 1 Jul 7 15:59:38 MediaTower kernel: mdcmd (49): spinup 2 Jul 7 15:59:38 MediaTower kernel: mdcmd (50): spinup 3 Jul 7 15:59:38 MediaTower kernel: mdcmd (51): spinup 4 Jul 7 15:59:38 MediaTower root: Jul 7 15:59:38 MediaTower root: /dev/sdi: Jul 7 15:59:38 MediaTower root: setting standby to 0 (off) Jul 7 15:59:42 MediaTower emhttpd: Stopping services... Jul 7 15:59:42 MediaTower emhttpd: shcmd (60465): /etc/rc.d/rc.libvirt stop Jul 7 16:00:42 MediaTower root: Domain 992b2eed-7034-08a5-5624-8a8ad130efd9 is being shutdown

I had a power failure today but my syslogs show a battery minimum was hit almost immediately. Then it says the power came back on. Here is an excerpt from today(june 16). The only parameter I have in UPS Settings is Battery % to Initiate Shutdown = 60%. Why is this happening? I am not convinced there was a power outage today my stove and microwave clocks still show the time. UPS reports 100% charge wih ~ 43 Minutes of run time. I manually powered the server back up ~ 6:30pm and everything seems fine so far. Jun 16 14:18:32 MediaTower apcupsd[15730]: Power failure. Jun 16 14:18:37 MediaTower apcupsd[15730]: Reached remaining time percentage limit on batteries. Jun 16 14:18:37 MediaTower apcupsd[15730]: Initiating system shutdown! Jun 16 14:18:37 MediaTower apcupsd[15730]: User logins prohibited Jun 16 14:18:37 MediaTower root: /usr/local/sbin/powerdown has been deprecated Jun 16 14:18:37 MediaTower init: Switching to runlevel: 0 Jun 16 14:18:37 MediaTower init: Trying to re-exec init Jun 16 14:18:37 MediaTower apcupsd[15730]: Power is back. UPS running on mains. Jun 16 14:18:37 MediaTower apcupsd[15730]: Allowing logins Jun 16 14:18:49 MediaTower kernel: mdcmd (51): nocheck cancel Jun 16 14:18:50 MediaTower emhttpd: Spinning up all drives... Jun 16 14:18:50 MediaTower emhttpd: shcmd (172794): /usr/sbin/hdparm -S0 /dev/sdi Jun 16 14:18:50 MediaTower kernel: mdcmd (52): spinup 0 Jun 16 14:18:50 MediaTower kernel: mdcmd (53): spinup 1 Jun 16 14:18:50 MediaTower kernel: mdcmd (54): spinup 2 Jun 16 14:18:50 MediaTower kernel: mdcmd (55): spinup 3 Jun 16 14:18:50 MediaTower kernel: mdcmd (56): spinup 4 Jun 16 14:18:50 MediaTower root: Jun 16 14:18:50 MediaTower root: /dev/sdi: Jun 16 14:18:50 MediaTower root: setting standby to 0 (off) Jun 16 14:18:53 MediaTower emhttpd: Stopping services... Jun 16 14:18:53 MediaTower emhttpd: shcmd (172796): /etc/rc.d/rc.libvirt stop Jun 16 14:18:55 MediaTower root: Domain 992b2eed-7034-08a5-5624-8a8ad130efd9 is being shutdown SysLog-20200616.txt

I was working within one of my VM's when my entire server just re-booted itself. Everything came back up but I don't like seeing it unscheduled. What caused this? This happened ~ 13:45. I am mirroring my Syslog and the attached is what happened up to the re-boot. mediatower-diagnostics-20200417-1354.zip

What is everyone's total processing time for parity check? I have 26 TB spread over 4 Drives(10/6/6/4) with a 12TB parity drive. This usually takes ~ 26 Hours to complete. My server has dual Xeon x5675 with 64GB Ram. Is the bottleneck Disk I/O? My server CPU total is running at 10% during parity check. CPU Utilization is always the same(whether running parity check or not running it). It picks 1 virtual core and runs it at 100% for a few minutes, then idles and repeats on a different virtual core. Just wondering if there are any secrets to decreasing the amount of time it takes. I see lag time in accessing shares as well as studdering in video playback over Plex that goes away when parity check is complete. I have looked at the Parity Check Tuning plugin but that is related to scheduling during of-peak time.

I put a GT 1030 in my unraid server. I updated my Vm settings but cannot start my VM. Attempt to start the Windows 7 VM and get the following error: internal error: process exited while connecting to monitor: 2020-02-22T15:41:56.500373Z qemu-system-x86_64: -device vfio-pci,host=0000:06:00.0,id=hostdev0,x-vga=on,bus=pci.0,addr=0x4: vfio 0000:06:00.0: failed to setup container for group 17: Failed to set iommu for container: Operation not permitted This was a working Windows 7VM that was using VNC Graphics. I get the error above after changing graphics & sound properties of the VM to use the GT 1030. I have ACS Override enabled as well as the following in my syslinux: append intel_iommu=on pcie_acs_override=downstream,multifunction vfio_vfio_iommu_type1.allow_unsafe_interrupts=1 Group 17 has the GT 1030 06:00:00 all by itself. Any ideas? Thanks In Advance, 12vman

Update: My issue was network-related. I had enabled a 2nd NIC on my server. I disabled the 2nd NIC and rebooted the server -. All is well now. I think I will leave it alone before I create more problems. I have been sailing with Deluge for some time now without issue. I have VPN enabled in Deluge routing thru Toronto. I rebooted my unraid server today. I am not able to open the Deluge WEBUI without first disabling the VPN. What is the issue? This was working fine before I did the re-boot. I just get the "site cannot be reached" error. Using port 8112. Here is my log: 2020-02-19 20:39:33,304 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2020-02-19 20:39:33,305 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2020-02-19 20:39:33,425 DEBG 'start-script' stdout output: [info] Default route for container is 172.17.0.1 2020-02-19 20:39:33,431 DEBG 'start-script' stdout output: [info] Adding 209.222.18.222 to /etc/resolv.conf 2020-02-19 20:39:33,436 DEBG 'start-script' stdout output: [info] Adding 84.200.69.80 to /etc/resolv.conf 2020-02-19 20:39:33,442 DEBG 'start-script' stdout output: [info] Adding 37.235.1.174 to /etc/resolv.conf 2020-02-19 20:39:33,448 DEBG 'start-script' stdout output: [info] Adding 1.1.1.1 to /etc/resolv.conf 2020-02-19 20:39:33,454 DEBG 'start-script' stdout output: [info] Adding 209.222.18.218 to /etc/resolv.conf 2020-02-19 20:39:33,459 DEBG 'start-script' stdout output: [info] Adding 37.235.1.177 to /etc/resolv.conf 2020-02-19 20:39:33,465 DEBG 'start-script' stdout output: [info] Adding 84.200.70.40 to /etc/resolv.conf 2020-02-19 20:39:33,471 DEBG 'start-script' stdout output: [info] Adding 1.0.0.1 to /etc/resolv.conf 2020-02-19 20:41:33,599 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:43:33,724 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:45:38,847 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:47:43,970 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:49:49,092 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error 2020-02-19 20:51:54,221 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error Then I shut down the Docker and deleted the Config Files in OpenVPN. Copied the original certificates back and changed my end point from Toronto to France. Same results in the logfile. Also looking at my Unraid Log I am seeing the following : Feb 20 07:36:16 MediaTower kernel: docker0: port 4(veth9c959ce) entered blocking state Feb 20 07:36:16 MediaTower kernel: docker0: port 4(veth9c959ce) entered forwarding state Feb 20 07:36:16 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:36:17 MediaTower kernel: eth0: renamed from vethde49b44 Feb 20 07:36:17 MediaTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth9c959ce: link becomes ready Feb 20 07:36:17 MediaTower kernel: docker0: port 4(veth9c959ce) entered blocking state Feb 20 07:36:17 MediaTower kernel: docker0: port 4(veth9c959ce) entered forwarding state Feb 20 07:38:37 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:38:37 MediaTower kernel: vethde49b44: renamed from eth0 Feb 20 07:38:37 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:38:37 MediaTower kernel: device veth9c959ce left promiscuous mode Feb 20 07:38:37 MediaTower kernel: docker0: port 4(veth9c959ce) entered disabled state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered blocking state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:38:41 MediaTower kernel: device veth55c0157 entered promiscuous mode Feb 20 07:38:41 MediaTower kernel: IPv6: ADDRCONF(NETDEV_UP): veth55c0157: link is not ready Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered blocking state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered forwarding state Feb 20 07:38:41 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:38:43 MediaTower kernel: eth0: renamed from veth37cc761 Feb 20 07:38:43 MediaTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth55c0157: link becomes ready Feb 20 07:38:43 MediaTower kernel: docker0: port 4(veth55c0157) entered blocking state Feb 20 07:38:43 MediaTower kernel: docker0: port 4(veth55c0157) entered forwarding state Feb 20 07:57:51 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:57:51 MediaTower kernel: veth37cc761: renamed from eth0 Feb 20 07:57:52 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:57:52 MediaTower kernel: device veth55c0157 left promiscuous mode Feb 20 07:57:52 MediaTower kernel: docker0: port 4(veth55c0157) entered disabled state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered blocking state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered disabled state Feb 20 07:59:46 MediaTower kernel: device vethc3f7b23 entered promiscuous mode Feb 20 07:59:46 MediaTower kernel: IPv6: ADDRCONF(NETDEV_UP): vethc3f7b23: link is not ready Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered blocking state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered forwarding state Feb 20 07:59:46 MediaTower kernel: docker0: port 4(vethc3f7b23) entered disabled state Feb 20 07:59:47 MediaTower kernel: eth0: renamed from veth3940a12 Feb 20 07:59:47 MediaTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc3f7b23: link becomes ready Feb 20 07:59:47 MediaTower kernel: docker0: port 4(vethc3f7b23) entered blocking state Feb 20 07:59:47 MediaTower kernel: docker0: port 4(vethc3f7b23) entered forwarding state

Prior to the upgrade I 1. Stopped all dockers 2. Shutdown all VMs 3. Disabled the Docker Engine 4. Disabled the VM Engine 5. Performed 6.8.1 Upgrade 6. Upgraded UD Plugin Could I have avoided this by doing it differently?

Ok I was able to do that and re-create my dockers in no time. All of my config settings were preserved. The share where my docker.img was located was on an unassigned device device(ssd). I also had sabnzbd complaining at the same time that it couldn't connect to the share(same share where docker.img was located). Now it is working fine. That is a bit concerning.