chazlarson

EDIT: Apparently I just needed to wait for a while, as both of these are now cleared up. I did install and subsequently remove the activ-lazylibrarian docker in there to see if it showed the same problems, but used a different port and app data location [it was 830 commits behind and didn't show the "127.0.0.1" problem]. Aside from that this one was just running for about 50 minutes. Two issues, one of which makes configuring it further difficult. I've just installed this fresh; there was no app data folder to start. Docker setup: [I only changed the indicated fields] Startup showing docker command: It's running, and lists the IP as I'd expect. The WebUI menu item seems to be pointing to the right place: Issue 1: When I select "WebUI" from the menu, or click the "192.168.1.2:5299" link, I get this: The URL in the address bar is now 127.0.0.1:5299. If I edit it to 192.168.1.2:5299, the UI loads. I can then bring up the settings panel, but clicking the save button gives me the can't connect because it's again going to 127.0.0.1. Changes are saved, but I have to edit the URL again to get back to the UI. Issue 2: Restarting the docker and forcing an update have no effect. Log is attached. Any suggestions on either front? ll-log.txt

Thanks! Had no idea that facility existed, and it looks like it's a more sensible solution to my nzbget problem, for sure.

I've been struggling with this, as well, in a different context. I installed the linuxserver Let's Encrypt! docker and then within it installed PlexRedirect and PlexEmail. Works great except that PlexEmail wants you to use cron to run it weekly to generate the new web page. I then realized that that crontab setting wouldn't stick between updates, which reminded me of the other thorn in my side. I use sickbeard_mp4_automator to convert all my downloads to m4v, but of course that gets lost every time I upgrade the nzbGet container. I solved it mostly with an install script that I keep in the userdata so when I upgrade the nzbget container I can log in using docker exec and run the script. I figured I'd do the same with Let's Encrypt and set up a script to recreate the cron entry. BUT THEN I realized that I can just run the script directly with the docker command: docker exec -ti letsencrypt python /config/www/PlexEmail/scripts/plexEmail.py and docker exec -ti nzbget sh /config/sickbeard-no-pause.sh Then I realized that the User Scripts plugin was running scripts in the UNRaid shell, and I bet I can do that there. I set up the User Scripts plugin to run that script every five minutes and the PlexEmail script every week. You can probably do something like that with your php.ini. I keep a modified autoProcess.ini in the appdata folder that my script copies into place; you could do the same thing with php.ini. Your script would copy your php.ini into place and reset whatever needs resetting [maybe apache/nginx needs to be restarted or what have you]; you could use a flag file that goes away when the container gets reset to control whether you need to do anything [if you even care about that; my script can run over and over without bollixing anything up], and then run the script every five minutes. When your Wordpress container gets reset, in no more than 5 minutes your custom setup will be restored.

I just swapped my setup into one of the 15-bay Rosewill cases. Very nice case; eight fans and very quiet. Often drops to $95 on Amazon, pretty routinely $95 on eBay. Has been as low as $65 on Amazon. https://www.amazon.com/Rosewill-Server-Chassis-Rackmount-Metal/dp/B0091IZ1ZG/ref=sr_1_1?ie=UTF8&qid=1480451654&sr=8-1&keywords=rosewill+15-bay

I just finished swapping my UNRAID server into a Rosewill 15-bay case. It's regularly $95 on Amazon. 8 fans and super quiet. Honestly, when i powered it up for the first time I had to look at all the fans to be sure they were running. It's one of the more economical many-bay cases i found. https://www.amazon.com/Rosewill-Server-Chassis-Rackmount-Metal/dp/B0091IZ1ZG

In my case, they're xfs.

In my case, at least, the dockers have never gone unresponsive. They continue to work. It's parts of the UNRAID UI that are not responsive, and the shares don't work.

Thanks. I've edited those messages so they don't confuse the issue in this thread.

Maybe interesting? UPDATE: NOT. This was apparently an unrelated issue having to do with Docker temp/log file locations. /dev/loop0 3.4G 3.4G 0 100% /var/lib/docker

I'm in this state again. Wait, today there's a difference; I have no shares or devices visible in the UI, CPU shows 0%, but the start/stop buttons are still present under Main. Starting and stopping the array brought the devices back but not the shares. I've updated the attached syslog; it should now include that stop/start event. After a reboot I'll run "tail /var/log/syslog -f" on the console downstairs. Once it fails again [in four days, if the pattern holds], I'll get you a screenshot, then delete my dockers and try it again. FWIW, right now: Clicking the log button: Jan 25 07:17:37 Tower dhcpcd[1324]: eth0: renew in 3600 seconds, rebind in 6300 seconds Jan 25 07:17:37 Tower dhcpcd[1324]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jan 25 07:17:37 Tower dhcpcd[1324]: eth0: IP address 192.168.0.100/24 already exists Jan 25 07:17:37 Tower dhcpcd[1324]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' RENEW Jan 25 07:17:37 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (1 of 2), next in 2.0 seconds Jan 25 07:17:39 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (2 of 2) Jan 25 07:33:07 Tower dhcpcd[1324]: eth0: xid 0x7cd12051 is for hwaddr d0:23:db:a8:6b:ad:00:00:00:00:00:00:00:00:00:00 Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: renewing lease of 192.168.0.100 Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: rebind in 2700 seconds, expire in 3600 seconds Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: sending REQUEST (xid 0xca5984da), next in 3.3 seconds Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: acknowledged 192.168.0.100 from 192.168.0.1 Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: leased 192.168.0.100 for 7200 seconds Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: renew in 3600 seconds, rebind in 6300 seconds Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: IP address 192.168.0.100/24 already exists Jan 25 08:17:37 Tower dhcpcd[1324]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' RENEW Jan 25 08:17:38 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (1 of 2), next in 2.0 seconds Jan 25 08:17:40 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (2 of 2) Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: renewing lease of 192.168.0.100 Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: rebind in 2700 seconds, expire in 3600 seconds Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: sending REQUEST (xid 0xa46cfb70), next in 3.5 seconds Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: acknowledged 192.168.0.100 from 192.168.0.1 Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: leased 192.168.0.100 for 7200 seconds Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: renew in 3600 seconds, rebind in 6300 seconds Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: IP address 192.168.0.100/24 already exists Jan 25 09:17:37 Tower dhcpcd[1324]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' RENEW Jan 25 09:17:38 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (1 of 2), next in 2.0 seconds Jan 25 09:17:40 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (2 of 2) Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: renewing lease of 192.168.0.100 Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: rebind in 2700 seconds, expire in 3600 seconds Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: sending REQUEST (xid 0x59e7eba), next in 4.4 seconds Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: acknowledged 192.168.0.100 from 192.168.0.1 Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: leased 192.168.0.100 for 7200 seconds Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: renew in 3600 seconds, rebind in 6300 seconds Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: IP address 192.168.0.100/24 already exists Jan 25 10:17:37 Tower dhcpcd[1324]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' RENEW Jan 25 10:17:38 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (1 of 2), next in 2.0 seconds Jan 25 10:17:40 Tower dhcpcd[1324]: eth0: ARP announcing 192.168.0.100 (2 of 2) Jan 25 11:06:29 Tower atd[17756]: File a000050171b4a2 is in wrong format - aborting Jan 25 11:07:20 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Attempting to generate Diagnostics.zip gives a 404. I can view four days of log in the Tools, but attempting to download gives a 404. Copy-pasted contents are attached. syslog.txt.zip

Docker is implicated or suspected?

Back in this state. Everything seems to be working except the shares. I can connect via ssh, I can connect to all dockers, but cannot connect to the shares and all parts of the UI that have to do with shares is empty. How can i get to the bottom of this? The only error I can see in the syslog as the WebUI shows it to me is: Jan 17 03:40:01 Tower logger: /usr/local/sbin/mover: line 44: echo: write error: No space left on device which starts happening four days into the latest uptime. There is no filesystem in the machine that is anywhere near full so far as i can see: Last login: Wed Jan 13 18:19:10 2016 from c-75-72-234-181.hsd1.mn.comcast.net Linux 4.1.13-unRAID. root@Tower:~# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 128M 3.1M 125M 3% /var/log /dev/sda1 3.8G 145M 3.6G 4% /boot /dev/md1 1.9T 261G 1.6T 14% /mnt/disk1 /dev/md2 1.9T 33M 1.9T 1% /mnt/disk2 /dev/md3 1.9T 33M 1.9T 1% /mnt/disk3 /dev/md4 1.9T 33M 1.9T 1% /mnt/disk4 /dev/sdb1 56G 11G 46G 19% /mnt/cache shfs 7.3T 261G 7.1T 4% /mnt/user0 shfs 7.4T 271G 7.1T 4% /mnt/user /dev/loop0 10G 4.8G 4.4G 53% /var/lib/docker root@Tower:~# Suggestions welcome. There must be some way to figure out what's dying.

I'm seeing the same thing. No fix yet, but you're not alone.

My array has very little on it. Where are you seeing that it's pretty full? 146G used on 4 2T disks. /dev/md1 1.9T 146G 1.7T 8% /mnt/disk1 /dev/md2 1.9T 33M 1.9T 1% /mnt/disk2 /dev/md3 1.9T 33M 1.9T 1% /mnt/disk3 /dev/md4 1.9T 33M 1.9T 1% /mnt/disk4 also, what's this: "and the mover..." Hey, now Dashboard and Main are empty. No disks listed on either tab. df -h still shows them, though. Any suggestions before I reboot?

It's in this state right now. I can't download Diagnostics.zip; I can navigate to that section of the tools, but clicking the button gives me a 404. I'm connected with Transmit, and can see that clicking the button creates the Diagnostics-DATE-TIME folder at the root of the filesystem, but all the files within are 0 length. Is there another way to generate the diagnostics.zip? Alternatively, I can apparently grab whatever is needed straight from the filesystem. Trying to export the syslog also gives a 404, so I copy-pasted and attached it. I can connect to existing Dockers' web UIs and create new Dockers. I can connect via ssh and all seems to be in place: ? ~ ssh [email protected] [email protected]'s password: Last login: Wed Jan 13 15:21:48 2016 from 192.168.0.105 Linux 4.1.13-unRAID. root@Tower:~# ls /boot/ System\ Volume\ Information/ bzroot* config/ ldlinux.c32* license.txt* make_bootable_mac* packages/ bzimage* changes.txt* install.txt* ldlinux.sys* make_bootable.bat* memtest* syslinux/ root@Tower:~# cd / root@Tower:/# ls -diagnostics-20160113-1522/ bin/ dev/ home/ lib/ mnt/ proc/ run/ sys/ usr/ -diagnostics-20160113-1536/ boot/ etc/ init@ lib64/ opt/ root/ sbin/ tmp/ var/ root@Tower:/# cd mnt root@Tower:/mnt# ls cache/ disk1/ disk2/ disk3/ disk4/ user/ user0/ root@Tower:/mnt# ls disk1 Books/ Incoming-Comics/ Movies/ Music/ Software/ TV/ appdata/ docker.img nzbget_downloads/ templates/ root@Tower:/mnt# ls cache appdata/ apps/ docker.img root@Tower:/mnt# ls disk2 root@Tower:/mnt# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 128M 2.6M 126M 2% /var/log /dev/sda1 3.8G 136M 3.7G 4% /boot /dev/md1 1.9T 146G 1.7T 8% /mnt/disk1 /dev/md2 1.9T 33M 1.9T 1% /mnt/disk2 /dev/md3 1.9T 33M 1.9T 1% /mnt/disk3 /dev/md4 1.9T 33M 1.9T 1% /mnt/disk4 /dev/sdb1 56G 11G 46G 19% /mnt/cache shfs 7.3T 146G 7.2T 2% /mnt/user0 shfs 7.4T 156G 7.2T 3% /mnt/user /dev/loop0 10G 4.0G 5.1G 45% /var/lib/docker root@Tower:/# I will leave it in this state in case there's anything anyone wants/needs from it. There must be something simple in my hardware or maybe flash drive. This same piece of hardware has been running as a FreeNAS machine for about a year, so I think the hardware is not implicated. I did add a SATA PCI card, but since all the drives are still online [cache is on that card] it would seem that it's not implicated. I welcome suggestions. UNRAID-log.txt