mikesp18

Members
  • Posts

    90
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

mikesp18's Achievements

Apprentice

Apprentice (3/14)

7

Reputation

  1. Wow. Thank you. How did you know the docker.img was corrupt? Maybe I won't nee to ask for help next time Followed the instructions, everything was back up and running in 10 minutes. I did need to clear the browser cache for one of the containers, but that was about it. The ability to tick off all the containers to reinstall and do it all at once was lovely.
  2. As I was sitting at the desk, I noticed that my Sabnzbd docker lost connection. I checked and the docker was running. It's the VPN version, so sometimes it drops out. So I restarted the docker and got a failed message. I stopped and restarted the Docker Service under Settings->Docker, and now I'm getting "Docker Service failed to start.". My first inclination is to restart the Unraid installation, but... I've made errors doing that before. What shall I try first. Thanks as always. grond-diagnostics-20211110-1236.zip
  3. orcrist-diagnostics-20210821-2347.zipsyslog.zip I'm getting pretty frustrated. I'm crashing roughly once every other day at this point. I thought the problem was the UPS triggering shutdowns, but alas, it's no longer hooked up via UPS. No recent hardware changes. The only thing obvious in the syslog is this message spammed 1000 times (exageration). ANy ideas? Tonight looks like around Aug 21 23:21, system was still powered on, the webui wouldn't log in, and physical screen was crashed at the GUI login screen, and the keyboard was unresponsive. Does this mean anything useful? Aug 21 23:21:48 Orcrist rsyslogd: file '/var/log/syslog'[9] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/2027 ] Aug 21 23:21:48 Orcrist rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2002.0 try https://www.rsyslog.com/e/2027 ]
  4. I think I figured it out. The UPS Daemon was triggering the shutdown I think. Unclear why, it is at full power. But, that's the least bad thing it could be.
  5. And another crash around 23:00 8/16/2021.syslog (3).zip
  6. syslog Well, just got a crash with syslog server running. I was watching a movie, so I know the server went down shortly before the restart. EDIT: looks like there is a filesize limit, and the errors spammed so hard to make the file 50mb. This is just the last 1mb ish of the file syslog1
  7. Thanks, Jorge. I had another crash while I was at work. I'll upload it in the morning. I had enabled a system log but had it writing to a local file and backing it up every 10 minutes. I was worried that backing it up to the flash drive would write too much data. Is that really an issue? Do I need to take the file off of the flash drive before I restart unRAID? If I restart the system will it overwrite the existing log file? Just curious about the order that I should do things.
  8. I am starting to get frequent problems with Unraid. It always seems to happen in the middle of the night, or when I'm at work. It's frustrating when the wife and kids complain when I get out of work and I have to try to trouble shoot. So, help me with my marriage. I'm attaching dianostics, and syslog. The system was up and running around 03:00am local, and was problematic when I notices around 14:00 local. The screen GUI was up on the local box but unresponsive. SSH was not working. WebGui was not working. I did have a drive problem yesterday that was solved in another thread (xfs_repair), though I suspect unrelated since this current issue is an ongoing issue. This has happened repeatedly, and requires a hard reset, which unfortunately then starts a parity check which runs around 36 hours. Any ideas? orcrist-diagnostics-20210717-1558.zip orcrist-syslog-20210717-2207.zip
  9. Phase 1 - find and verify superblock... - block cache size set to 3012408 entries Phase 2 - using internal log - zero log... zero_log: head block 578753 tail block 574745 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... invalid start block 2690876492 in record 46 of bno btree block 4/44382387 agi unlinked bucket 4 is 386238468 in ag 4 (inode=8976173060) sb_icount 299168, counted 290912 sb_ifree 8198, counted 14220 sb_fdblocks 598797622, counted 631121483 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 7 - agno = 5 - agno = 3 - agno = 6 - agno = 4 - agno = 2 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 8976173060, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (3:576454) is ahead of log (1:2). Format log to cycle 6. XFS_REPAIR Summary Fri Jul 16 13:06:15 2021 Phase Start End Duration Phase 1: 07/16 13:03:37 07/16 13:03:37 Phase 2: 07/16 13:03:37 07/16 13:04:14 37 seconds Phase 3: 07/16 13:04:14 07/16 13:04:30 16 seconds Phase 4: 07/16 13:04:30 07/16 13:04:30 Phase 5: 07/16 13:04:30 07/16 13:04:32 2 seconds Phase 6: 07/16 13:04:32 07/16 13:04:47 15 seconds Phase 7: 07/16 13:04:47 07/16 13:04:47 Total run time: 1 minute, 10 seconds done This was the output with -Lv. It seems to be working and the drive remounted. Any way to see what's in this lost and found file? It's tiny. Actually says 0 bytes
  10. Phase 1 - find and verify superblock... - block cache size set to 3012408 entries Phase 2 - using internal log - zero log... zero_log: head block 578753 tail block 574745 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. This is the output with -v. Should I use the -L option?
  11. Phase 1 - find and verify superblock... - block cache size set to 3012408 entries Phase 2 - using internal log - zero log... zero_log: head block 578753 tail block 574745 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... invalid start block 2690876492 in record 46 of bno btree block 4/44382387 agi unlinked bucket 4 is 386238468 in ag 4 (inode=8976173060) sb_icount 299168, counted 290912 sb_ifree 8198, counted 14220 sb_fdblocks 598797622, counted 631121483 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... free space (4,48984675-48984973) only seen by one free space btree - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 5 - agno = 7 - agno = 4 - agno = 6 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 8976173060, would move to lost+found Phase 7 - verify link counts... would have reset inode 8976173060 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Jul 15 16:44:00 2021 Phase Start End Duration Phase 1: 07/15 16:43:29 07/15 16:43:29 Phase 2: 07/15 16:43:29 07/15 16:43:30 1 second Phase 3: 07/15 16:43:30 07/15 16:43:46 16 seconds Phase 4: 07/15 16:43:46 07/15 16:43:46 Phase 5: Skipped Phase 6: 07/15 16:43:46 07/15 16:44:00 14 seconds Phase 7: 07/15 16:44:00 07/15 16:44:00 Total run time: 31 seconds
  12. I removed a share and then tried to add a new one. My system log started throwing many errors such as I stopped the array and restarted it. Now under the Array Operations on the Main tab, I see It is giving me the option to format that drive as it is unmountable. This drive was working fine a few seconds prior. Any ideas? I have seen some UDMA_CRC errors on this drive before, but it is a relatively new drive (I seem to frequently get UDMA_CRC errors despite checking and replacing SATA cables). Before I do something stupid like resetting the server, could you guys look at the log and smart report and let me know what you think? I appreciate it. orcrist-diagnostics-20210715-1613.zip orcrist-smart-20210715-1613.zip
  13. One more question. In the past, I've used the Minecraft Server console via putty with the following command as per the documentation faqs. However, now I get an error message. It was making it difficult to work out a previous problem. How can I correct this? The result:
  14. That worked. Thank you, sir. For reference if others are looking, here is the successful log line.