Hello, Thanks for the warning, Luca Boccassi.
I'm aware of the implications of increasing the soft limit. I read many discussions on the subject on the web while looking for a solution, and understand the rationale of the Debian decision to set the soft limit to 1024 and the hard limit to 1048576 in recent releases. I agree to that and expect that modern, non-select()-using applications set the soft limit themselves to deliberately indicate that they want more file descriptors. I filed a bug for Wine as it didn't work as expected in this case. (https://bugs.winehq.org/show_bug.cgi?id=55363) That should not be discussed here, though. What I report is that after changing every possible settings I could find documentation for on the web, the soft limit stays unchanged in the initial session of a freshly opened gnome-terminal in the graphical DE. The higher soft limit gets properly set everywhere else as expected, including opening a new session in the gnome-terminal with sudo to the same user, or temporarily setting the value with 'ulimit -n XXXX'. This means to me that something overrides the global settings from systemd & pam_limits.so in gnome-terminal initialization or a parent process, or that it takes a path that simply doesn't load the systemd/pam_limits settings. I would like to know if I simply missed something in my attempt to configure a higher soft limit, or if the issue lies within systemd or another component/application. How can I check that? Regards. P.S. Quoting the original message seems broken for me when using the 'reply' link on the Debian Bug page. The generated quote was limited to a few lines of my own quoted message in your reply. I removed it as it was meaningless. -- Olivier F. R. Dierick o.dier...@piezo-forte.be
