twooly Posted January 22, 2019 Share Posted January 22, 2019 Today noticed my syslog filling up and found theses messages repeating over and over about every 5-10 seconds. Jan 22 08:28:12 unRaid rpcbind[9117]: connect from xxxxx.xxxx.xxxx.xxxx to getport/addr(mountd) xxxxx.xxxx.xxxx.xxxx is an ip address of a server mounted to an unraid nfs share. Is there a way to stop these messages from happening over and over filling my log space up? Quote Link to comment
zigzig Posted June 7, 2019 Share Posted June 7, 2019 Hello, I have installed the 6.7 version (from 6.3.5) and now, I have the same messages every 10 sec (before, from 6.3.5, I never see that. Is it a problem ? Thx Quote Link to comment
[email protected] Posted January 27, 2020 Share Posted January 27, 2020 Has this been resolved? I've had the same problem for months. Quote Link to comment
billchurch Posted February 28, 2020 Share Posted February 28, 2020 On 1/27/2020 at 6:51 PM, [email protected] said: Has this been resolved? I've had the same problem for months. Same here, it seems unnecessary and is just noise making it difficult to find real problems in the log. Quote Link to comment
autumnwalker Posted March 12, 2020 Share Posted March 12, 2020 Also curious about this. There must be a way to suppress it. Quote Link to comment
ho0ber Posted March 14, 2020 Share Posted March 14, 2020 I am also having this issue - it's making it very difficult to troubleshoot other issues on my server. Anyone getting anywhere on suppressing these? Quote Link to comment
autumnwalker Posted April 6, 2020 Share Posted April 6, 2020 Bump. Would really like to have these suppressed. I'm searching around online, but not seeing anything non-Unraid specific either. Quote Link to comment
ljm42 Posted April 6, 2020 Share Posted April 6, 2020 can someone please upload their diagnostics showing the problem? Quote Link to comment
ZipsServer Posted April 11, 2020 Share Posted April 11, 2020 Here is an example from my system. I had just rebooted so the syslog shouldn't be terribly long, but it should show the ridiculous number of rcpbind log messages. mastertower-diagnostics-20200411-1743.zip Quote Link to comment
derekvm Posted June 7, 2020 Share Posted June 7, 2020 Did anyone ever find a resolution for this issue? It's started happening for me too. Quote Link to comment
ZipsServer Posted June 19, 2020 Share Posted June 19, 2020 (edited) My server just crashed for the second time due to memory errors. I am pointing my finger at this issue filling up the log and causing errors that I don't understand I was not able to download diagnostics (I am assuming some process was killed that it needed) but I was able to download the syslog. Happy to share it privately. Jun 18 21:40:37 MasterTower kernel: Timer-Scheduler invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0 Jun 18 21:40:37 MasterTower kernel: Timer-Scheduler cpuset=07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0 mems_allowed=0 Jun 18 21:40:37 MasterTower kernel: CPU: 2 PID: 16549 Comm: Timer-Scheduler Tainted: G W 4.19.107-Unraid #1 Jun 18 21:40:37 MasterTower kernel: Hardware name: System manufacturer System Product Name/F1A75-V PRO, BIOS 2507 01/29/2015 Jun 18 21:40:37 MasterTower kernel: Call Trace: Jun 18 21:40:37 MasterTower kernel: dump_stack+0x67/0x83 Jun 18 21:40:37 MasterTower kernel: dump_header+0x66/0x289 Jun 18 21:40:37 MasterTower kernel: oom_kill_process+0x9d/0x220 Jun 18 21:40:37 MasterTower kernel: out_of_memory+0x3b7/0x3ea Jun 18 21:40:37 MasterTower kernel: mem_cgroup_out_of_memory+0x94/0xc8 Jun 18 21:40:37 MasterTower kernel: try_charge+0x52a/0x682 Jun 18 21:40:37 MasterTower kernel: ? __alloc_pages_nodemask+0x150/0xae1 Jun 18 21:40:37 MasterTower kernel: mem_cgroup_try_charge+0x115/0x158 Jun 18 21:40:37 MasterTower kernel: __add_to_page_cache_locked+0x73/0x184 Jun 18 21:40:37 MasterTower kernel: add_to_page_cache_lru+0x47/0xd5 Jun 18 21:40:37 MasterTower kernel: filemap_fault+0x238/0x47c Jun 18 21:40:37 MasterTower kernel: __do_fault+0x4d/0x88 Jun 18 21:40:37 MasterTower kernel: __handle_mm_fault+0xdb5/0x11b7 Jun 18 21:40:37 MasterTower kernel: handle_mm_fault+0x189/0x1e3 Jun 18 21:40:37 MasterTower kernel: __do_page_fault+0x267/0x3ff Jun 18 21:40:37 MasterTower kernel: ? page_fault+0x8/0x30 Jun 18 21:40:37 MasterTower kernel: page_fault+0x1e/0x30 Jun 18 21:40:37 MasterTower kernel: RIP: 0033:0x154aa86131c0 Jun 18 21:40:37 MasterTower kernel: Code: Bad RIP value. Jun 18 21:40:37 MasterTower kernel: RSP: 002b:0000154a655fab60 EFLAGS: 00010202 Jun 18 21:40:37 MasterTower kernel: RAX: ffffffffffffff92 RBX: 0000560b17d40fa0 RCX: 0000154aa8612ed9 Jun 18 21:40:37 MasterTower kernel: RDX: 0000000000000000 RSI: 0000000000000080 RDI: 0000560b17d40fc8 Jun 18 21:40:37 MasterTower kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 Jun 18 21:40:37 MasterTower kernel: R10: 0000154a655fabc0 R11: 0000000000000246 R12: 0000560b17d40fe0 Jun 18 21:40:37 MasterTower kernel: R13: 0000560b17d40fc8 R14: 0000154a655fac60 R15: 0000560b17d40fc4 Jun 18 21:40:37 MasterTower kernel: Task in /docker/07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0 killed as a result of limit of /docker/07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0 Jun 18 21:40:37 MasterTower kernel: memory: usage 512000kB, limit 512000kB, failcnt 16659 Jun 18 21:40:37 MasterTower kernel: memory+swap: usage 512000kB, limit 1024000kB, failcnt 0 Jun 18 21:40:37 MasterTower kernel: kmem: usage 6576kB, limit 9007199254740988kB, failcnt 0 Jun 18 21:40:37 MasterTower kernel: Memory cgroup stats for /docker/07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0: cache:4292KB rss:500828KB rss_huge:4096KB shmem:0KB mapped_file:396KB dirty:132KB writeback:132KB swap:0KB inactive_anon:4KB active_anon:501112KB inactive_file:2168KB active_file:1884KB unevictable:0KB Jun 18 21:40:37 MasterTower kernel: Tasks state (memory values in pages): Jun 18 21:40:37 MasterTower kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Jun 18 21:40:37 MasterTower kernel: [ 3423] 0 3423 50 1 28672 0 0 s6-svscan Jun 18 21:40:37 MasterTower kernel: [ 3489] 0 3489 50 1 28672 0 0 s6-supervise Jun 18 21:40:37 MasterTower kernel: [ 3797] 0 3797 50 1 28672 0 0 s6-supervise Jun 18 21:40:37 MasterTower kernel: [ 3800] 99 3800 638611 125200 2191360 0 0 mono Jun 18 21:40:37 MasterTower kernel: Memory cgroup out of memory: Kill process 3800 (mono) score 982 or sacrifice child Jun 18 21:40:37 MasterTower kernel: Killed process 3800 (mono) total-vm:2554444kB, anon-rss:500796kB, file-rss:0kB, shmem-rss:4kB Jun 18 21:40:37 MasterTower kernel: oom_reaper: reaped process 3800 (mono), now anon-rss:0kB, file-rss:0kB, shmem-rss:4kB Edited June 19, 2020 by ZipsServer Quote Link to comment
ZipsServer Posted June 29, 2020 Share Posted June 29, 2020 (edited) Again, Posting here because of more kernel OOM erros. This time I was unable to stop containers and the webui went down (nginx 500). Still unable to run diagnostics. Edited June 29, 2020 by ZipsServer Quote Link to comment
SkippyAlpha Posted September 25, 2020 Share Posted September 25, 2020 Would like to add that I too am getting a massive amount of these messages after mounting an nfs unraid share from another of my servers Quote Link to comment
Khadgar Posted October 13, 2020 Share Posted October 13, 2020 I am getting tons of these messages due to a computer mounting nfs shares, causing it to fill up my syslog ~24 hours. Quote Link to comment
Khadgar Posted October 15, 2020 Share Posted October 15, 2020 (edited) My difficulties here with rpcbind logs are due to three computers mounting nfs shares. Looked around after getting crickets from Unraid on this, and a solution that works for me is to make the timeout on automounts on the three computers to something larger than 10 minutes. automount -t 3600 This will cause it to unmount non-busy mounts every hour instead of 10 minutes. I don't know if there is a way to set up a different timeout per mount (if someone knows please reply), but this works for my purposes and might for others here. Edited October 15, 2020 by Khadgar Pasted the wrong command, clarified what command does Quote Link to comment
dlandon Posted April 11, 2021 Share Posted April 11, 2021 A temporary fix is to install the Enhanced Log plugin and set up a log filter. Go to 'Settings->Enhanced Log Settings' and click on the 'Syslog Filter' tab. Enter the following in the text area: "to getport/addr" Then click 'Apply'. The getport/addr messages will blocked from the log. Quote Link to comment
dlandon Posted April 17, 2021 Share Posted April 17, 2021 Fix is available here: Quote Link to comment
ZappyZap Posted May 17, 2021 Share Posted May 17, 2021 (edited) sadly this did not fix the issue at least for me the fix works on my second unraid. I will look into what happen on my other unraid server. Edited May 17, 2021 by ZappyZap 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.