I'm seeing a recurring log entry (every 4 minutes) from a Docker (GS-Server).  Such a useful docker, love how well it works except for this log issue.  I've spoken with the Docker creator who is unable to recreate the error and Goodsync tech support.  Goodsync says the problem is a "known issue" with Linux and requires some kind of update to fix (they said google it, but I've not been able to find anything specific and recent).

 

So I'm posting this in hopes that someone is aware of a fix.  While everything works fine, my log is filling up with useless data!  I've attached a copy just FYI...

 

Thanks in advance!

 

hunternas-syslog-20200210-2052.zip

I continue to see this error every few minutes.  I've researched the problem with the developers of GoodSync and they have identified it as an update needed to the kernel.  Is there a formal process to get this reviewed with the UnRaid team?  This is what the developer posted as a response:

 

William replied (2020/12/20 01:23 pm EST)	
I googled it and think they say that you need to update kernel.
you can do the same search.

You wrote (2020/12/20 12:32 pm EST)	
Are you aware of a solution or way to suppress the message?

William replied (2020/12/20 11:32 am EST)	
this is a known bug in Linux, has nothing to do with GS

Mike replied (2020/12/19 11:30 am EST)	
Hello,
The error you are receiving is related to Linux and not GoodSync.
Linux - netlink: 4 bytes leftover after parsing attributes in process
You will need to address this with your device directly.

Thank you.
You wrote (2020/12/19 09:55 am EST)	
Using Goodsync Connect on Linux. I'm seeing entries in my Linux log (see below). Shows up every 4 minutes. Any idea what it is or how to turn this off? Config issue? Bug? Thanks in advance!

================ example line from LOG
DEC 19 08:02:30 HunterNAS bunker: exported 277738 files from /mnt/disk1. Duration: 00:01:27 Dec 19 08:02:40 HunterNAS bunker: exported 408250 files from /mnt/disk11. Duration: 00:01:37 Dec 19 08:05:37 HunterNAS kernel: netlink: 4 bytes leftover after parsing attributes in process gs-server'.
Dec 19 08:09:37 HunterNAS kernel: netlink: 4 bytes leftover after parsing attributes in process gs-server'. Dec 19 08:13:37 HunterNAS kernel: netlink: 4 bytes leftover after parsing attributes in process gs-server'.

Thanks a bunch.  This is one of those things that just fills up the log...  I'm not sure of a way to suppress the log entry from the APP.

Edited December 29, 20205 yr by jeffreywhunter

what version Unraid? Newer kernel on 6.9 don't know if it would help or not

1 hour ago, trurl said:

what version Unraid? Newer kernel on 6.9 don't know if it would help or not

Sorry, should have said.  Version 6.8.3 2020-03-05.  If 6.9 has a new kernel, then perhaps that is the resolution.  Is there a way to validate plugin compatibility with 6.9?

Edited December 29, 20205 yr by jeffreywhunter

Assuming you have FCP installed, then Tools - Update Assistant.  Not definitive, but as close as you'll get

Reopening this conversation a year later.  The problem has continued through a number of 6.9 updates.  Now at v6.9.2, all plugins have been kept up to date, but I still see the log entries filling up my log and crashing the server.

 

Jan 2 14:11:05 HunterNAS kernel: netlink: 4 bytes leftover after parsing attributes in process `gs-server'.

 

Server locks up every few days - even the console locks up and the PC is unresponsive (won't even respond to numlock key).  I'm at a loss about what to do next with the annoyance.  Would it make sense to do a daily delete of the log files with a CRON job (hack I know, but...)?  Other ideas how to keep my server from crashing all the time...

hunternas-diagnostics-20220102-1411.zip

2 years later and I still have this "HunterNAS kernel: netlink: 4 bytes leftover after parsing attributes in process `gs-server'." every 60 sec's in my log.  Obviously not a show stopper, but it IS an annoyance clogging up my log.  Any ideas out there?  Goodsync Connect is an excellent way to backup my PC's to unRaid.  Just wish it didn't clog my log...