I posted in the Docker forum about all kinds of strange issues I am having with some containers.  Unraid itself seems to be running just fine and because of that I was looking at program and container logs but I stupidly never looked at the syslog.  I finally did and am seeing a bunch of errors like these:

 

Mar  3 18:01:59 WOPR emhttpd: error: get_temperature, 4050: Resource temporarily unavailable (11): popen: /usr/sbin/smartctl -n standby  -A /dev/sdk
Mar  3 18:01:59 WOPR emhttpd: error: get_temperature, 4050: Resource temporarily unavailable (11): popen: /usr/sbin/smartctl -n standby  -A /dev/sdp
Mar  3 18:01:59 WOPR emhttpd: error: get_temperature, 4050: Resource temporarily unavailable (11): popen: /usr/sbin/smartctl -n standby  -A /dev/sdj

 

Mar  3 18:15:05 WOPR emhttpd: error: shcmd_test, 1188: Resource temporarily unavailable (11): system

 

Mar  5 08:47:11 WOPR shfs: fuse: error creating thread: Resource temporarily unavailable

 

Additionally, one problem I am having is with my Docker container failing when trying to playback a video file and it's log also says "Resource temporarily unavailable".  Anybody have an idea what's going on here?

 

 

wopr-diagnostics-20190305-1817.zip

Anyone have any ideas?

Sent from my Pixel 3 using Tapatalk

Your errors seem to start during docker start up:

Mar  2 20:21:18 WOPR rc.docker: sonarr: started succesfully!
Mar  2 20:21:18 WOPR kernel: traps: ffdetect[22886] general protection ip:403a38 sp:7ffeeab81710 error:0 in ffdetect[400000+15000]
Mar  2 20:21:18 WOPR kernel: traps: ffdetect[23079] general protection ip:403a38 sp:7ffdc6782ed0 error:0 in ffdetect[400000+15000]

which is after Emby has already started.

See here: 

Try running without Emby for a while and see if things improve.

Thanks for the reply.  I tried running without Emby and I am still getting the errors I posted above.  I also looked at rthe event log for my mobo and I it shows these lines:

 

58697	2018/10/20 15:05:28		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted
58698	2018/11/10 09:35:50		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted
58699	2018/12/10 14:35:27		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted
58700	2018/12/27 15:22:30		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted
58701	2019/01/16 19:38:30		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted
58702	2019/02/01 17:20:09		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted
58703	2019/02/12 04:43:13		Memory	Correctable Memory ECC @ DIMMF1(CPU2) - Asserted

 

I was fearful that might be indicating a bad RAM module but I ran 1 24 hour memtest with no errors.  Additionally, other containers are also acting "odd" like I posted in this thread:

 

 

Edited March 8, 20197 yr by RockDawg

3 minutes ago, RockDawg said:

I was fearful that might be indicating a bad RAM module

It does.

 

3 minutes ago, RockDawg said:

but I ran 1 24 hour memtest with no errors. 

That's expected since the errors are being correct so Memtest doesn't detect anything, DIMM still needs to be replaced, though it's unrelated to your current problems, if there is an uncorrectable error the server will halt.

2 minutes ago, johnnie.black said:

It does.

 

That's expected since the errors are being correct so Memtest doesn't detect anything, DIMM still needs to be replaced, though it's unrelated to your current problems, if there is an uncorrectable error the server will halt.

 

 

Thanks.  That's good to know.  I will replace.  Now to figure out what's causing my problems.  My Docker containers have been all but useless for the past week and it's really inconvenient (it's amazing how my unraid server has become so important in my day to day life).

Try in safe mode and/or unisnstall all plugins you don't really need, even if just temporarily, also stop all dockers you can, maybe you can find the culprit, I believe there are or were one or two dockers with memory leaks.

I disabled Docker in settings and ran Unraid for a couple errors with none of the errors showing up in the log.  I re-enabled it and have been slowly starting my containers one by one waiting a couple hours between each and so far everything is good.  Emby, Nzbget and Sonarr have been running longer than usual without problems so you just may be on to something.

 

Stupid question but how can you identify a container with a memory leak?  Will it just eat up all the available RAM?

I am still running with the bare minimum containers and everything seems to be running good so far but I did get the following lines in my system log:

 

Mar  9 03:15:08 WOPR kernel: mce: [Hardware Error]: Machine check events logged
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: HANDLING MCE MEMORY ERROR
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: CPU 8: Machine Check Event: 0 Bank 9: 8c000051000800c1
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: TSC abc3b4fc0e1a4 
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: ADDR b3e0a2000 
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: MISC 90004000400228c 
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: PROCESSOR 0:206d7 TIME 1552119308 SOCKET 1 APIC 20
Mar  9 03:15:08 WOPR kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0xb3e0a2 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:1 rank:0)

 

The was no additional lines in my mobo's system event log, but is this more proof of bad RAM?

5 hours ago, RockDawg said:

I am still running with the bare minimum containers and everything seems to be running good so far but I did get the following lines in my system log:

 

Mar  9 03:15:08 WOPR kernel: mce: [Hardware Error]: Machine check events logged
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: HANDLING MCE MEMORY ERROR
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: CPU 8: Machine Check Event: 0 Bank 9: 8c000051000800c1
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: TSC abc3b4fc0e1a4 
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: ADDR b3e0a2000 
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: MISC 90004000400228c 
Mar  9 03:15:08 WOPR kernel: EDAC sbridge MC1: PROCESSOR 0:206d7 TIME 1552119308 SOCKET 1 APIC 20
Mar  9 03:15:08 WOPR kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0xb3e0a2 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:1 rank:0)

 

The was no additional lines in my mobo's system event log, but is this more proof of bad RAM?

Yes 

On 3/8/2019 at 1:52 PM, johnnie.black said:

It does.

 

That's expected since the errors are being correct so Memtest doesn't detect anything, DIMM still needs to be replaced, though it's unrelated to your current problems, if there is an uncorrectable error the server will halt.

so if I'm getting this error its a def. memory?  URGH - Thanks

 

Aug 30 11:13:09 Skynet kernel: traps: ffdetect[15522] general protection ip:40412a sp:7ffd8e9ae8d0 error:0 in ffdetect[403000+c000]

Aug 30 11:13:09 Skynet kernel: traps: ffdetect[15523] general protection ip:40412a sp:7fff984e2ed0 error:0 in ffdetect[403000+c000]

Just now, cbr600ds2 said:

so if I'm getting this error its a def. memory?  URGH - Thanks

 

Aug 30 11:13:09 Skynet kernel: traps: ffdetect[15522] general protection ip:40412a sp:7ffd8e9ae8d0 error:0 in ffdetect[403000+c000]

Aug 30 11:13:09 Skynet kernel: traps: ffdetect[15523] general protection ip:40412a sp:7fff984e2ed0 error:0 in ffdetect[403000+c000]

Not necessarily.  I've seen that a fair amount on server's running Plex et al that do transcoding.

1 minute ago, Squid said:

Not necessarily.  I've seen that a fair amount on server's running Plex et al that do transcoding.

uhm... that def. makes me nervous.  I'm not running Plex (emby user here) and I don't do transcoding.  

You're using some container that is using ffmpeg.

9 minutes ago, Squid said:

You're using some container that is using ffmpeg.

That could be emby then.  thanks!