Just had an issue where I could only logon via the Console to the SRX300. After logging on as root, I noticed the following error continuously displaying on the screen:
kern.maxfiles limit exceeded by uid 65534, please see tuning(7)
I read kb article: https://kb.juniper.net/InfoCenter/index?page=content&id=KB21548 and applied the workaround, which gives you a workaround for 8 seconds, not much time to do anything. It also mentions this is a bug in older Junos versions. I am currently running version: 15.1X49-D140.2 and as far as I can see, this bug should not be present in this version of junos.
Completing the command "sysctl -a | grep files" shows the following:
root@ethernet-test% sysctl -a | grep fileskern.maxfiles: 2500kern.maxfilesperproc: 2500kern.openfiles: 1108
The "kern.openfiles" is increasing all the time and I'm guessing that when it hits 2500 the error will happen again?
Is there a way to increase this 2500 please or another option to stop this occuring?
Anyone seen this error before because of anything in particular, like turning on some IDS?
Okay. As this is a test system we can do certain things we couldn't in a live system.
I cannot find any bugs related to this issue on this version of Junos.
Strangely, I completed a "load factory-default" and rebooted and could still connect to the device. Hardly a factory-default..... so, I have now zeroised the system and rebooted.
The reason for this is so that I can have the IDS as it was originally and see if the file count increases again.
Will let you all know the results.
This has not resolved the issue. The file count is still increasing.
I think I will have to monitor this until it hits the 2500 file amount and see what happens. That could take a couple of days so will keep this open in the hope that someone can let me know if there are any bugs.
Please open a ticket with JTAC and upload the outputs of following commands collected from shell as root user once every day to track the increase and investigate furthe:
lab@SRX> start shell user root
Password: <<<<<<< Enter root password
root@SRX% sysctl -a | grep files
Please check ZTP (phone-home) feature is enabled on it. If yes disable it.
Yes, when I ran fstat I noticed a lot of "phone-home" entries but was noit sure if it was required or not.
When I came in this morning the issue was there again.
I will disable it and test.
Okay. Disabled the phone-home service and rebooted the device.
I have chcked the sysctl -a | grep files and find that it is resting around the 1150 mark and not increasing. Given that I tried from my laptop to get to the site in the command and it comes up with a security warning, then when you click "details and continue to website" you get a 404 error. This is why the file space is filling and the error occuring.
It may be an idea to let Juniper know that this website is not operational and remove it from their code.
Either way, it's working again so thank you for your help.
The url https://redirect.juniper.net is not an actual website - it's basically a webservice meant for the devices to get information on how and from where they should be bootstrapped. So getting an http 404 when accessing the url is not an actual error - but a friendly error page would have been nice.
That said, it should not make the SRX300 unresponsive due to kern.maxfiles.
JTAC seem to be unaware of this issue - I've just wasted about an hour on the phone to them pointing at a different issue (https://kb.juniper.net/InfoCenter/index?page=content&id=KB27337&cat=QFX_SERIES&actp=LIST) as being '100% the cause'.
Thanks for this solution (my boss found it, so kudos to him too), it has worked perfectly for me as well. Interestingly I have 2 SRX345s configured identically (slightly different IPs for VRRP, both running 15.1X49-D140.2) and although one of them showed the problem, the other did not. There is no default route, and one of them as the master will be trying to bring up a VPN, so I am going to assume at this point that the phone home was waiting for that to come up and still being spawned.
We've just bought about 100 SRX300 series routers, so this going out into production would have been a major problem