Set a high default open files setting in init script.

[derSascha]

This commit sets 32768 as a default open file limit in current shell env and should be better than the default distributions settings (e.g. default on ubuntu 12.04 is 1024).

[damm]

Does this work for you @derSascha ?

Unfortunately in https://github.com/derSascha/influxdb/blob/default-max-open-files-in-init-script/scripts/init.sh#L100 start-stop-daemon is used. So unless the behavior changed your ulimit -n should have no effect.

[derSascha]

Works well on Ubuntu 12.04.5 LTS. Why shouldn't this work with start-stop-stop daemon?

Unfortunately start-stop-daemon does not evaluate limits.conf settings and using ulimits this way seems to be a common approach.

See http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daemon/459183#459183
or e.g. elasticsearch init script: https://github.com/elasticsearch/elasticsearch/blob/master/src/deb/init.d/elasticsearch#L152

[damm]

@derSascha Actually start-stop-daemon has nothing to do with limits.conf. This is PAM specific; so you need to have pam loading your limits here.

Like you need this in /etc/pam.d/su

session    required   pam_limits.so

Unfortunately most of what Elasticsearch does also expects PAM to load the limits.conf as well. A non-root user cannot elevate the open files past the hard limit (if i recall) and really we should not be running influxdb as root.

It's quite a pain in the butt to get limits to be honored properly without having PAM load it up.

Maybe a /etc/pam.d for influxdb that matches with start-stop-daemon so we can do this without modifying distro files?

Edited to make the right pam declaration.

[derSascha]

@damm I didn't change any limits.conf in my commit, i simply set require limits as root at runtime and it works great :-) So why change any pam configuration here?

Basic idea was:

1. set limits as root in current env (init script)
2. launch start-stop-daemon as influxdb user and use limit settings from current env

The following works well too:

root@host:~# ulimit -n
1024
root@host:~# su -c 'ulimit -n' influxdb 
1024
root@host:~# ulimit -n 12345
root@host:~# ulimit -n
12345
root@host:~# su -c 'ulimit -n' influxdb 
12345

No distro files have to be changed and we can run influxdb as non root user as usual.

So unless the behavior changed your ulimit -n should have no effect.

What do you mean with this? Have you tested it? It works perfectly on ubuntu!

[damm]

@derSascha you set it with pam so it works out of the box without any shennigans such as (ulimit)

Personally I wish people would try and configure limits.conf (or limits.d) than use work arounds as having it work always is awesome. If someone slips up and starts it by hand it still works right.

Don't forget ulimit -n can be lost upon bash --login if the limits are not being consumed (passed properly)

[derSascha]

@damm i don't change any pam settings! My limits.conf is empty (contains only comments). Running influxdb without the unlink addition results in "to many open file errors". Adding the ulimit line (this pull-request) works fine.

Pleas read: http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daemon/459183#459183

According to this post, it is IMPOSSIBLE to configure start-stop-daemon limits via pam configuration. I don't understand what you mean. Do you know any tricks how to configure start-stop-daemon limits via limits.conf?

[damm]

@derSascha my experience is opposite. You cannot get start-stop-daemon to honor limits without pam and limits.conf. Really what it comes down to is we need a proper debian package that can enable whatever bits it needs to be fully working (out of the box).

It's been said time and time again. You can find the latest in #816

P.S. I think I know start-stop-daemon fairly well; I'm not flawless. But hoping that ulimits are honored (and passed) is hoping for the best. In my personal experience I've done it time and time again only to find my limits are not being honored.

But really this should be handled in #816 with preseeding and other bits.