ridge

My unRAID log is still saying this: 151114 21:21:36 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 21:21:36 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 21:21:37 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 21:21:37 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 21:21:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended etc

Step 1: Move .err files... root@Gallifrey:~# docker exec -it mariadb /bin/bash root@aab3299b69a3:/# cd /config/databases root@aab3299b69a3:/config/databases# ls -l total 176347 -rw-r----- 1 abc users 20089 Nov 12 21:29 4325730b7f89.err -rw-rw---- 1 abc users 16384 Nov 14 03:23 aria_log.00000001 -rw-rw---- 1 abc users 52 Nov 14 03:23 aria_log_control -rw-rw---- 1 abc users 50331648 Nov 14 03:23 ib_logfile0 -rw-rw---- 1 abc users 50331648 Nov 14 03:23 ib_logfile1 -rw-rw---- 1 abc users 79691776 Nov 14 03:23 ibdata1 -rw-rw---- 1 abc users 0 Oct 12 20:50 multi-master.info drwx------ 2 mysql users 2976 Oct 12 20:50 mysql drwx------ 2 abc users 1512 Nov 8 19:10 owncloud drwx------ 2 abc users 2744 Oct 12 20:50 performance_schema root@aab3299b69a3:/config/databases# mv 4325730b7f89.err 4325730b7f89.old root@aab3299b69a3:/config/databases# exit exit Step 2: Restart docker from unRAID admin Step 3: No new .err file created.

Definitely not.

Thought I had. Oh well. I installed MariaDB originally a couple of months ago. Created my database there and then. Nothing was imported/migrated. Only one database running (for ownCloud). It's been running fine until this problem. Nothing has been migrated, no other MariaDB docker has been used. It's all been the Linuxserver docker right from the get-go.

Learned something new, thanks. Unfortunately, I still have a non-functional MySQL installation. I've tried connecting from another computer with no luck. So I thought maybe the root password is wrong. Made sure the docker was running. Ran a docker exec -it mariadb /bin/bash. Tried to change the password. Got this: root@aab3299b69a3:/# mysqladmin -u root password <password> mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")' Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! That's not right...

I have no idea what that debian-sys-maint@localhost user is. Certainly nothing I've created. I've only created a database for ownCloud, and that has its own user (named "owncloud") associated to it. Also, the log on pastebin isn't reflecting what you asked. It's just the most recent log on there. I'm concerned that the docker says it's logging to a .err file that doesn't actually exist.

root@Gallifrey:~# docker exec -it mariadb cat /config/databases/aab3299b69a3.err cat: /config/databases/aab3299b69a3.err: No such file or directory There is a .err file in there, but its date is Nov 12. Output at http://pastebin.com/CcTit5ta

Existing container, existing data.

So I changed the name of my existing container in order to add a new one, and the update must have run successfully, because the container is now starting properly. However, my troubles aren't over. I'm now getting the following repeating in the log: ----------------------------------- _ _ _ | |___| (_) ___ | / __| | |/ _ \ | \__ \ | | (_) | |_|___/ |_|\___/ |_| Brought to you by linuxserver.io ----------------------------------- GID/UID ----------------------------------- User uid: 99 User gid: 100 ----------------------------------- We are now refreshing packages from apt repositorys, this *may* take a while Nov 14 13:00:38 aab3299b69a3 syslog-ng[60]: syslog-ng starting up; version='3.5.3' 151114 13:00:38 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:38 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:38 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 13:00:39 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:39 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 13:00:40 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:40 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:40 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 13:00:42 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:42 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:42 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 13:00:43 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:43 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:43 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 13:00:44 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:44 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:44 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 151114 13:00:45 mysqld_safe Logging to '/config/databases/aab3299b69a3.err'. 151114 13:00:45 mysqld_safe Starting mysqld daemon with databases from /config/databases 151114 13:00:45 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

It's an existing installation, with one database (for ownCloud) in it.

For what? I start the docker, it sits with the message above, and then stops itself after about 5 seconds. Leaving it alone does nothing.

Strange problem that only just started happening today. I start the container, it runs for a few seconds, then stops. The docker simply won't stay running. The log only shows this for each start: ----------------------------------- GID/UID ----------------------------------- User uid: 99 User gid: 100 ----------------------------------- Setting up mariadb-server-10.0 (10.0.22+maria-1~trusty) ... I'm kinda relying on Mariadb as ownCloud is set up to work with it. No database, no ownCloud. Any suggestions? Further info?

OK never mind. The two people who were having problems reset their clients and THEN it worked. All good here!

Having the same issue. I can post the plex log, but I believe this is where things are going wrong. Sep 24, 2015 22:31:54 [0x2ba506401700] DEBUG - Starting a transcode session 3g2tn2irlh4zpvi at offset -1.0 (stopped=1) Sep 24, 2015 22:31:54 [0x2ba506401700] WARN - WARNING: Couldn't create directory /transcode/plex-transcode-3g2tn2irlh4zpvi-129a71fa-dbd9-4b49-b729-af719709f128 Sep 24, 2015 22:31:54 [0x2ba506401700] DEBUG - [universal] Using local file path instead of URL: /media/TV/Scandal (2012)/Season 5/Scandal.(2012).S05E01.Heavy Is the Head.HDTV-720p.mkv Sep 24, 2015 22:31:54 [0x2ba506401700] DEBUG - Job running: XDG_CACHE_HOME='/config/Library/Application Support/Plex Media Server/Cache/' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources/' '/usr/lib/plexmediaserver/Resources/Plex New Transcoder' '-noaccurate_seek' '-i' '/media/TV/Scandal (2012)/Season 5/Scandal.(2012).S05E01.Heavy Is the Head.HDTV-720p.mkv' '-map' '0:0' '-codec:0' 'copy' '-bsf:0' 'h264_mp4toannexb,h264_plex' '-map' '0:1' '-codec:1' 'aac' '-strict:1' 'experimental' '-cutoff:1' '15000' '-channel_layout:1' 'stereo' '-b:1' '258k' '-f' 'matroska' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-' '-start_at_zero' '-copyts' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/3g2tn2irlh4zpvi/progress' Thanks for this, would jump on to our IRC Channel to help out with debugging this ? Just wanted to report that the update from last night has resolved the transcoding issue. Playback is working properly now. Thanks! Nothing has changed for me. Upgraded and did a restart (just to be sure), and it's the same problem. Nothing plays when you're external to my network. I'll post a log when I can get out of meetings.

Had this docker working without a problem for some time. Remote access worked a treat. Since updating earlier today to the new container, remote access hasn't worked (confirmed by friends outside my network), and on restart the remote access tab will not connect. Server's connection hasn't changed - only change was the update to the Plex container. Anything changed? Settings I need to update? Variables I'm using: PUID: 99 PGID: 100 VERSION: plexpass Thanks! Edited to add: Restarted a few more times and the remote access connects. Friends can see contents of my server, browse, etc. But nothing plays outside the network. I added a /transcode path in case that had anything to do with it, but didn't seem to help.

Thanks Frank, but I pre cleared the new drive and it was just fine. ohwiler, thanks. I'll order a couple of SFF-8087 cables. Worth trying that first. However, you're right in the frustrating feeling that comes from not knowing what the actual problem is. Though it does give me the impetus to get that 24-bay Norco case for array #2.

Update: Parity check completed fine. Array is back up and functioning normally, but I'm still left with the question of how to figure out what component is faulty.

Looks like --rebuild-tree did the trick. I'm sure I've lost a few (unimportant) media files along the way, but nothing like the loss I was fearing. I'm now running a parity check, and so far so good. So, looks like the sequence of events is this: [*]Disk 10 red balls after a monthly parity check. Shows a few hundred errors [*]Mistakenly assume the disk is at fault [*]Replaced disk with spare that has been precleared and has no errors [*]"New" disk 10 won't rebuild. Not in its bay, not directly connected to the one remaining motherboard slot. Refuses. [*]Replace directly connected "new" disk 10 with original disk 10. [*]Rebuild successful. Conclusion: The original disk was fine. The replaced disk was faulty. The connection is bad somehow in the bay (backplane? Cable? No idea). The replaced drive did actually have a fault - or it gained a fault during the first write in the bad bay. I hope to update the thread with a successful parity check within the next day and a half, but in the meantime my question: How can I determine what component is at fault? Norco backplane? Cable to the backplane? Something else? I'm now officially at my technical limit. Complication is that my array is completely full, so no spare bays to use.

Thanks ohiwiler. That's exactly what I ended up doing. The new disk failed completely. The original managed to rebuild, but now shows as unformatted. So, I ran another reiserfsck --check /dev/md10 and got the below. Now, per this thread, I'm running --rebuild-tree. root@Gallifrey:~# reiserfsck --check /dev/md10 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md10 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Tue Jul 7 01:30:15 2015 ########### Replaying journal: Done. Reiserfs journal '/dev/md10' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. \/ 1 (of 26|/ 1 (of 96//126 (of 129\block 124427444: The level of the node (34576) is not correct, (1) expected the problem in the internal node occured (124427444), whole subtree is skipped / 4 (of 96|/ 95 (of 96\block 789628251: The level of the node (13331) is not correct, (1) expected the problem in the internal node occured (789628251), whole subtree is skipped finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 2 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Tue Jul 7 02:28:49 2015 ###########

Ugh. Posted in v6. Should have been in v5. Sorry. EDIT: Thank you for moving the post!

Hi guys, Background info: Running a Norco 4220 case 19 4TB drives in array, plus 1 4TB parity and a SSD cache Drive 10 is red balled Replaced with new drive, drive still red balls Sequence of events: [*]Drive 10 red balls after a monthly parity check. Shows a few hundred errors [*]Replaced drive with spare that has been precleared and has no errors [*]Start rebuild. Come back a few hours later to a red balled drive 10 with 428 (or so) errors. Try to run SMART test, cannot (see below) [*]Decide to try again, in case this is a fluke. Stop array, remove, etc to get to where I can re-add the same drive again. Had to reboot before I could re-add drive. [*]Rebuild array. Same results. Drive 10 has about 428 errors [*]Place array into maintenance mode in order to run reiserfsck --check /dev/md10. Results below Latest syslog is attached (I foolishly didn't get a syslog from before I rebooted...sorry). Errors start at around the 02:11 timestamp. Regarding the SMART report, here's what I get when running the command: root@Gallifrey:~# smartctl -a -A /dev/sdt smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: /6:0:5:0 Product: Physical block size: 0 bytes Lowest aligned LBA: 8949 Logical block provisioning enabled, LBPRZ=0 >> Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Results of reiserfsck --check /dev/md10: root@Gallifrey:~# reiserfsck --check /dev/md10 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md10 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Fri Jul 3 09:41:25 2015 ########### Replaying journal: Done. Reiserfs journal '/dev/md10' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 593982 Internal nodes 3637 Directories 427 Other files 4266 Data block pointers 600329559 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Fri Jul 3 16:33:43 2015 ########### From the reading I've done this sounds like it could be cabling, but I wanted to check in before I go doing anything else. I'm not exactly confident of my abilities to troubleshoot beyond what I've already done, so any insight you guys can offer would be greatly appreciated. syslog-2015-07-03.txt.zip

After reading the upgrade instructions I'm even more gunshy about upgrading: Is upgrading to rc12a really the best thing to do, given the invalid parity, and disabled disk? Or does it not matter because it looks like I'm going to be rebuilding the array anyway?

Thanks Gary. I suspected as much, to be honest. After a reboot, I was able to run a SMART status on the drive that failed. It's attached. smart.txt

I have a problem, and I think I got myself into more of a mess trying to solve it. I had what looked like a bad drive. So - given that I had a spare sitting in my array - I stopped the array and switched the old for the new drive, then brought it back online to start rebuilding the data from parity. Except it didn't work, because either the second drive was also bad, or I have a problem elsewhere. This is where it gets a little hazy as it was very late and I was tired, but I put back the old drive, and did an initconfig to reset everything. And then started the array to rebuild the parity drive. The problem is, that didn't work. It got about 50% of the way through, and then quit after about 20 million (literally) parity errors that it was correcting. The attached screenshot shows you what I'm facing, after doing an initconfig and resetting the drives to their original place. I've uploaded my syslog here as it's much too large to attach: https://dl.dropboxusercontent.com/u/15336/syslog-2013-05-28.txt.zip What's my next step? FYI, I have two new drives arriving in the next day or so. 2 4TB drives, one as a parity replacement, the other a new data drive. Edited to add: Running version 5.0-beta14. I'm gunshy about upgrading until things are more stable, to be honest. Smart report for the drive is: Statistics for /dev/sde Hitachi_HDS5C3020ALA632_ML2220F31LGNUE smartctl -a -d ata /dev/sde smartctl 5.40 2010-10-16 r3189 [i486-slackware-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

2 days later, and not a single crash running 6a. I'm more than a little concerned that 14 seemed so unstable, bringing my entire system down within 10 minutes, when, after downgrading, the server is once again rock solid. I'll be sticking with 6a for the foreseeable future, it seems.