CrimsonTide Posted December 16, 2020 Share Posted December 16, 2020 (edited) Hello! My server is crashing nearly every night. Not sure the exact time, but I always wake up and it crashed overnight. Things I've tried so far: 1) Switching from DVB version of 6.8.3 to 6.9.0-rc1 2) Run syslog tail - last few entries before connection closed is: Dec 15 23:00:16 SkynetUNRAID crond[2217]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Dec 16 00:00:12 SkynetUNRAID crond[2217]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Dec 16 01:00:12 SkynetUNRAID crond[2217]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null 3) Save syslog to flash - last entry is identical as above. skynetunraid-diagnostics-20201216-1703.zip Diagnostics attached. Edit: I notice that SSD Trim is scheduled to run nightly at 4am - will disable this and see if it makes a difference. Edited December 16, 2020 by CrimsonTide Quote Link to comment
CrimsonTide Posted December 17, 2020 Author Share Posted December 17, 2020 Update - disabling trim didn't help, still crashed overnight. Nothing else is in the scheduler as far as I can tell that would occur every overnight. Quote Link to comment
trurl Posted December 17, 2020 Share Posted December 17, 2020 Does it happen if you disable dockers? Why are you running mover so often? Quote Link to comment
CrimsonTide Posted December 17, 2020 Author Share Posted December 17, 2020 I can try disabling dockers overnight. What is the issue with running the mover hourly? I figured it kept the cache drive at low use in case there was an incoming large file. It looks like all the mover syslog entries are terminating without error. Quote Link to comment
trurl Posted December 17, 2020 Share Posted December 17, 2020 1 hour ago, CrimsonTide said: What is the issue with running the mover hourly No real issue, but some people seem to think they can keep cache from filling by running mover more often even while they continue to write to their server. Mover is intended for idle time. It is impossible to move from cache to slower array as fast as you can write to cache. If writing more than cache can hold it is better to not use cache, for example during initial data load. Quote Link to comment
CrimsonTide Posted December 18, 2020 Author Share Posted December 18, 2020 (edited) Ok, with docker disabled it didn't crash overnight. However, when I enabled docker in the morning, it crashed immediately. Yet, when it reboots, docker comes up normally. Edited December 18, 2020 by CrimsonTide Quote Link to comment
Squid Posted December 18, 2020 Share Posted December 18, 2020 Are you running organizr? Quote Link to comment
CrimsonTide Posted December 18, 2020 Author Share Posted December 18, 2020 Nope. Quote Link to comment
trurl Posted December 18, 2020 Share Posted December 18, 2020 8 hours ago, CrimsonTide said: with docker disabled it didn't crash overnight Possibly some host path that isn't actual storage and so fills RAM. Quote Link to comment
CrimsonTide Posted December 19, 2020 Author Share Posted December 19, 2020 Tonight it crashed as usual - I had docker service enabled but all dockers off. Quote Link to comment
trurl Posted December 19, 2020 Share Posted December 19, 2020 Your docker.img isn't configured to be on any user share, it is at the root of /mnt/user. The usual convention is to put it in system share, or alternatively, to a specific disk. Do you know what disk it is on? Quote Link to comment
CrimsonTide Posted December 19, 2020 Author Share Posted December 19, 2020 Docker vDisk location: /mnt/user/DockerImg/docker.img Default appdata storage location: /mnt/user/appdata/ How do I tell what disk /mnt/user is on, since it's not on a share? Quote Link to comment
trurl Posted December 19, 2020 Share Posted December 19, 2020 /mnt/user is all the user shares. The user shares are just the top level folders on all disks. If a disk has a top level folder there is a user share named for that folder, and any top level folders with that same name on other disks is part of that same user share. 7 hours ago, trurl said: Your docker.img isn't configured to be on any user share, it is at the root of /mnt/user. The usual convention is to put it in system share, or alternatively, to a specific disk. Do you know what disk it is on? I was mistaken about that, perhaps I was looking at the diagnostics of some other user. You are correct about the location of your docker.img, so it is in a user share named DockerImg and it is all on cache so that's all OK. Quote Link to comment
CrimsonTide Posted December 20, 2020 Author Share Posted December 20, 2020 (edited) I'm tempted to replace the power supply since that seems to usually be the culprit in random-shutdowns in the past on other systems. I'm just a little skeptical it's a hardware issue since it only happens overnight. I stress the server during the day with high CPU usage and it does fine. Memtest was fine also. Edit - crashing randomly during the day now too. Edited December 20, 2020 by CrimsonTide Quote Link to comment
CrimsonTide Posted December 24, 2020 Author Share Posted December 24, 2020 Swapped out the power supply and it's been up now for 3 days. Hopefully that was the issue! 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.