8 minutes ago, nuhll said:

Because the system needs to reserve ram and cpu for each request, since unraid doesnt has any protection, as far as i know, they could try to get into unraid like 1000 times a second if they want. (brute force)

It may not related, but you risk ur network of a crazy security hole. Unraid is designed atm for safe networks. (LAN)

 

The log shows itself that they did not try and get into unraid 1000 times a second. It looks like typical http requests to get password lists from some sort of known insecure web server setup and they are blocked constantly since I have ssh open on port 80, not a web server.

The system may reserve ram and cpu but on what process? Not shfs. shfs is the process that appears to have a memory leak issue.

 

The network security part is off topic for this thread.

 

Youre so smart, why u ask then questions here?

 

Does the log show connections to your ftp server? No. Who does know what alese it not logged. If they really flood ur server with requests, they could not show up in the same time frame as they tried to connect. On which p

 

Since no one has this memory leak, its something on your system. I also thought its unraid bug, but it was just a plugin...

 

Its just pretty easy, pack it behind a fw and check if the problem is still there after restart and waiting some time.

 

As far as i know shsf could be anything, its creating the user shares you use for ur dockers, plugins, system and so on... high utilizeration of this, means hes doin something heavy.. for me it was the cache plugin. (even after stopping this PLUGIN!!!)

Edited January 23, 20188 yr by nuhll

2 minutes ago, nuhll said:

Youre so smart, why u ask then questions here?

 

Does the log show connections to your ftp server? No. Who does know what alese it not logged. If they really flood ur server with requests, they could not show up in the same time frame as they tried to connect.

 

Since no one has this memory leak, its something on your system. I also thought its unraid bug, but it was just a plugin...

 

I really do appreciate you and others commenting to try and troubleshoot. I just think it is very obvious that my open port 80 for sshd is not the root cause of this issue. Not only does it not make sense, it was not an issue before updating to 6.4 and yet as soon as I updated to 6.4 I have to restart my server every 3 days or so.

I am not the OP, they also have the same issue so that is at least 2 people with the issue.

I will try and find a time I can run in safe mode without plugins, and not turn on any dockers AND block port 80 in my firewall, and I will review and see what memory usage looks like.

It is just unfortunate since other people depend on services on my server. I will definitely not be updating right away for any future unraid releases.

The problem is just that there is no specifc thing behind shsf, if it would be bugged, all would have the same problems.

 

Easiest way to troubleshoot is disable all plugins, always restart without enabling them, test.

 

If that not helps, try VM, DOckers,

 

If that not help, block 80.

 

So we can say 100% its not "a usual error"

 

I also didnt thought it would be a plugin, bc i disabled

Edited January 23, 20188 yr by nuhll

Tried blocking outside access and restarting. Still creeps up about 150MB of ram usage per hour. Will have to find a good time to test with plugins and dockers disabled.

8 hours ago, nuhll said:

The problem is just that there is no specifc thing behind shsf, if it would be bugged, all would have the same problems.

That is not how bugs generally work. Bugs that affects everyone are the good guys because they are so easy to find - and so are almost always found by the developer long before release.

 

But there seems to be an issue somewhere with shsf - it's just a question of figuring out what it takes to trig the issue. If it's uninitialized memory, it might even be impossible to find a specific sequence of events that sets off the problem.

 

A traditional way to figure out what is wrong is to force a core dump that can be sent to the developer. But the bad thing with shfs is that a core dump of that process would contain actual user file data.

For a bit of additional info, the two shfs processes on my machine are the following with 4094 being the one that keeps using more memory over time:

 

Based on lack of results on google I am guessing shfs is proprietary to unraid so I was not able to find anything explaining the options/flags. I'm also not sure where I could change them safely and permanently even if I did.

root 4081 1 0 Jan22 ? 00:00:02 /usr/local/sbin/shfs /mnt/user0 -disks 2046 -o noatime,big_writes,allow_other
root 4094 1 2 Jan22 ? 00:19:54 /usr/local/sbin/shfs /mnt/user -disks 2047 2048000000 -o noatime,big_writes,allow_other -o remember=330

 

7 hours ago, pwm said:

A traditional way to figure out what is wrong is to force a core dump that can be sent to the developer. But the bad thing with shfs is that a core dump of that process would contain actual user file data.

 

Do you have a recommended one liner to get a core dump for PID 4094?

We already had this:

 

 

They wont react before you shut down every "user is wrong" possibility. Like VMs, Dockers, Plugins. There limetech trys to explain what it is.

 

Edited January 23, 20188 yr by nuhll

Seems to me they screwed something up with their "improved shfs"

 

Literally nothing has changed since upgrading and that upgrade changed shfs and now shfs has a memory leak. Figuring out root cause might be hard but figuring out that shfs is the problem source seems pretty straightforward to me.

 

The idea that any sort of docker or vm or plugin issue would ALLOW shfs to take up 80% of memory would still be considered a shfs issue imo. Imagine if a kernel update did such a thing and people blamed user programs for it.

Improved shfs/mover

The unRAID user share file system (shfs) has been improved in two areas.

First, we now make use of FUSE read_buf/write_buf methods. This should result in significant throughput increases.

Second, the mover script/move program no longer uses rsync to move files/directories between the cache pool and the parity array. Instead the move program invokes a new shfs ioctl() call. This should result in complete preservation of all metadata including atime and mtime.

If i code a sh1t program for windows, which uses windows functions to do his stuff and lock ur computer, its also not windows fault.

Edited January 23, 20188 yr by nuhll

unraid is linux, not windows and I am referring to updates breaking things. If windows updates and breaks user programs that is windows' fault even if the programs are poorly written.

The kernel is essential to linux and shfs is essential to unraid. Regressions like this should not be blamed on docker, VMs or plugins even if disabling them were to make the issue go away.

https://lkml.org/lkml/2012/12/23/75
 

Quoted from above:
"If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?"

 

Edited January 23, 20188 yr by ffiarpg

So i guess u start coding and help them.

I can't because shfs isn't open source as far as I can tell.

I dont know.

 

Just try without dockers and plugins, if that dont help, then i dont know.

If it doesn't work without dockers or plugins then what is the point of even having a server? I understand you are out of options, I am asking for help from people who know more than you, or me.

They will tell you the same.

 

Thats how you find out where the problem is.

 

Maybe you are right and its a bug, but we wont find out if you dont exclude all other things.

Edited January 24, 20188 yr by nuhll

Hi,

 

I'm having the same issue with two different servers (shfs use of memory increases and increases).

 

After a little initial research, the main suspect is transmission container (linuxserver.io version), when its startet the shfs memory usage increses slowly and steady, if I stop it, the usage only moves a little. The servers hardware and configuration are different and only a few plugins and transmission container are the same, I'm planning on checking other bt client and discard the common plugins.

 

At least that's my case at the moment. 

I noticed the same correlation but it does still increase albeit slowly with all plugins and dockers off if I read and write via samba/cifs.

 

Definitely seems to point to a memory leak from the updates made to shfs. I have been restarting my server once a week waiting for Limetech to do something about this.

R u guys using cache dirs? All my troubles went away after disabling (the plugin) and restarting (server) this plugin.

Edited February 14, 20188 yr by nuhll

I uninstalled cache dirs for a week or two and saw no improvement so I reinstalled it yesterday so at least I can have good performance between weekly restarts.

Try without all dockers/plugins and restart, if it still happens, its unraid, if not, its a plugin/docker. "Which may be using shsf in a wrong way"

If a plugin or docker causes shfs to memory leak THAT IS STILL A FLAW IN SHFS. I'm not sure why that is so difficult to understand. 

 

 

IF A APP IS DOIN STUPID STUFF 192703123 TIMES A SECOND and SHSF USES MUCH RAM TO DO THIS STUFF, THEN ITS NOT. IS IT SO HARD TO UNDERSTAND?

 

There are 2 ways:

 

1.) Try to find out under what circumstances this happens, it does not happen to all customers!

2.) Say its a bug, dont help to resolve it

Edited February 14, 20188 yr by nuhll

Because if I turn off every app, it doesn't free up additional RAM. That's why.

I had the same problem.

 

I didnt listen to the ppl who told me its not a bug.

 

I also just disabled it, nothing changed. (so i also thought THIS IS A BUG!!!11)

 

BUT, disabling AND restarting fixed it.

 

Then i enabled the plugin with correct settings, 0 problems since weeks.

Edited February 14, 20188 yr by nuhll