Cocalc docker and haproxy FD limit

[Angela Hicks]

I run the latest Cocalc docker on a machine running Fedora 31.  Recently the server stopped opening files and reported an error "too many files open", so after restarting the machine to get it working again, I took a look at the log files for the docker image.  I'm repeatedly seeing the same warning on the haproxy server: 

* Starting haproxy haproxy

[WARNING] 154/142953 (17) : [/usr/sbin/haproxy.main()] Cannot raise FD limit to 4016, limit is 1024.

[WARNING] 154/142953 (17) : [/usr/sbin/haproxy.main()] FD limit (1024) too low for maxconn=2000/maxsock=4016. Please raise 'ulimit-n' to 4016 or more to avoid any trouble.

cp /projects/conf/nopassphrase.pem /run/haproxy.pem && chmod og-rwx /run/haproxy.pem

I can try to raise the FD limit and hope that solves the problem, but I wanted to make sure this isn't a sign of a bigger problem. Should I expect the server to need to have so many files open at once? 

There aren't very many users of the server (3 or 4 this summer) and the server hadn't been up very long (about a week), although I had been creating a lot of 3d graphics with it in one of the notebooks.  (I'm not sure what actions cause files to be opened in large enough numbers to be relevant to the limit.)

Thanks for any thoughts!

[William Stein]

I would definitely raise the limit. 1024 is really small for a
complicated web service, and your OS can easily handle a much large
number of file descriptors.

> --
> CoCalc: Collaborative Calculation in the Cloud -- https://cocalc.com
> ---
> You received this message because you are subscribed to the Google Groups "CoCalc" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cocalc+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/cocalc/3548932a-8bee-4586-98f9-08713f2d6f1b%40googlegroups.com.



--

Best Regards,
William Stein

CEO, SageMath, Inc.
https://cocalc.com

[Angela Hicks]

Thank you for the advice.  Raising the limit didn't go smoothly (I'll post a separate message for others benefit) but I think it is unrelated to this issue, so I wanted to take the moment to say thanks (as always) for you your help!

-Angela

On Wednesday, June 3, 2020 at 1:03:12 PM UTC-4, William Stein wrote:

I would definitely raise the limit.  1024 is really small for a
complicated web service, and your OS can easily handle a much large
number of file descriptors.


On Wed, Jun 3, 2020 at 9:59 AM Angela Hicks <anh...@lehigh.edu> wrote:
>
> I run the latest Cocalc docker on a machine running Fedora 31.  Recently the server stopped opening files and reported an error "too many files open", so after restarting the machine to get it working again, I took a look at the log files for the docker image.  I'm repeatedly seeing the same warning on the haproxy server:
>
> * Starting haproxy haproxy
> [WARNING] 154/142953 (17) : [/usr/sbin/haproxy.main()] Cannot raise FD limit to 4016, limit is 1024.
> [WARNING] 154/142953 (17) : [/usr/sbin/haproxy.main()] FD limit (1024) too low for maxconn=2000/maxsock=4016. Please raise 'ulimit-n' to 4016 or more to avoid any trouble.
> cp /projects/conf/nopassphrase.pem /run/haproxy.pem && chmod og-rwx /run/haproxy.pem
>
> I can try to raise the FD limit and hope that solves the problem, but I wanted to make sure this isn't a sign of a bigger problem. Should I expect the server to need to have so many files open at once?
>
> There aren't very many users of the server (3 or 4 this summer) and the server hadn't been up very long (about a week), although I had been creating a lot of 3d graphics with it in one of the notebooks.  (I'm not sure what actions cause files to be opened in large enough numbers to be relevant to the limit.)
>
> Thanks for any thoughts!
>
> --
> CoCalc: Collaborative Calculation in the Cloud -- https://cocalc.com
> ---
> You received this message because you are subscribed to the Google Groups "CoCalc" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to coc...@googlegroups.com.