Help with errors in syslog


Recommended Posts

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

Link to comment

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.

Link to comment

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 by RockDawg
Link to comment
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.

Link to comment
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).

Link to comment

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?

Link to comment

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?

Link to comment
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 

Link to comment
  • 1 year later...
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]

Link to comment
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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.