Kong 1.4.0 - ulimit is currently set to "1024". For better performance set it to at least "4096" using "ulimit -n"

Installation/Setup
1

Hello,

I run Debian linux (Debian 4.9.65-3+deb9u2) and Kong 1.4.0 community edition. I’m trying to understand why I’m still getting this warning below in the the /var/log/daemon.log and /var/log/syslog.log.

ulimit is currently set to "1024". For better performance set it to at least "4096" using "ulimit -n"

Here is what I set before I starting Kong. I have set the OS hard and soft limits to 65536 by setting in /etc/security/limits.conf to this below.

*               hard    nofile            65536
*               soft    nofile            65536

After these were set, I ran sysctl -p for the changes to take effect. I have verified that these are set by running ulimit -Hn and ulimit -Sn. I set the worker_rlimit_nofile 65536; in the /usr/local/kong.nginx.conf file. Every time I have restarted kong that message will show up in those two log and I’m not understanding why it would warn on this with all the limits set as explained above. Anybody have any ideas on this on why this still shows up? Did I miss a ulimit configuration?

Thanks,
Mike

1 Like
2

Please make sure the ulimit is correctly configured for the Unix user under which Kong process is running.

3

Hello @hbagdi

Kong is running under this process, which runs as root.

ps -ef |grep -i kong

root     18135     1  0 21:18 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx -p /usr/local/kong -c nginx.conf

Below are the ulimit setting for hard and soft for root user. So not sure why Kong thinks it’s still using 1024.

# su - root
# whoami
root
# ulimit -Sn
8192
# ulimit -Hn
8192

I did update the /etc/security/limits.conf from * to root and rebooted, which didn’t make a difference as I still get that warning.

root              hard    nofile            65536
root              soft    nofile            65536

Any other things to check?

Thanks,
Mike

4

Hello,

How is your Kong started? Can you post your startup script/systemd service config in here please.

Thanks,
Datong

5

Hello @datong.sun,

We use service kong start or systemctl start kong.service. Below is the contents of the service config.

# cat /etc/systemd/system/kong.service
[Unit]
Description="Kong service"
After=syslog.target network.target

[Service]
User=root
Group=root
Type=forking
ExecStart=/usr/local/bin/kong start -c /etc/kong/kong.conf --nginx-conf /usr/local/kong/nginx-custom.conf
ExecReload=/usr/local/bin/kong reload -c /etc/kong/kong.conf --nginx-conf /usr/local/kong/nginx-custom.conf
ExecStop=/usr/local/bin/kong stop

[Install]
WantedBy=multi-user.target

Thanks,
Mike

6

This is a limitation of systemd. You need to set LimitNOFILE in your systemd config based on the value you want (https://www.freedesktop.org/software/systemd/man/systemd.exec.html)

1 Like
7

Hello @p0pr0ck5,

Thank you for this info. That is what it was and that resolved that messaged showing up in /var/log/daemon.log and /var/log/system.log. This is what I did below to apply it.

  1. Added this below to /etc/systemd/system.conf

    DefaultLimitNOFILE=65536

  2. Reloaded daemon with systemctl daemon-reload

  3. Stopped and started Kong with the following:

    service kong stop
    service kong start

  4. Checked the limits of the Kong process similar to this below.

    ps -ef kong root 1916 1 0 22:58 ? 00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx -p /usr/local/kong -c nginx.conf

    cat /proc/1916/limits |grep 'open files'

    It showed this below for output:
    Max open files 65536 65536 files

  5. Check the log files to make sure the 1024 warning is not showing up anymore after restarting kong.

    grep 1024 /var/log/syslog |grep kong
    grep 1024 /var/log/daemon.log |grep kong

  6. The grep above did not show the 1024 ulimit warning anymore.

The message in the logs that sparked this thread is kind of misleading as ulimit -n won’t fix this issue when running on system running systemd.

I’m considering this issue resolved. Thank you to everybody that responded.

Mike