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, 20205 yr by CrimsonTide

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.

Does it happen if you disable dockers?

 

Why are you running mover so often?

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.

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.

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, 20205 yr by CrimsonTide

Are you running organizr?

Nope.

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.

Tonight it crashed as usual - I had docker service enabled but all dockers off.

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?

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?

/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.

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, 20205 yr by CrimsonTide

Swapped out the power supply and it's been up now for 3 days. Hopefully that was the issue!