| blizzow | Anyone here installed waydroid on devuan? If so, how did it go? | 03:49 |
|---|---|---|
| Soltis | Why would ulimit -n return 1024 when the system limits.conf is unlimited? | 05:33 |
| gnarface | not sure, but there's a difference between hard and soft limits, and there's also a difference between whether you're local or ssh'd in sometimes, at least in containers... i'm vague on it | 05:34 |
| gnarface | (containers can be subject to the host system's setting i think?) | 05:35 |
| rwp | Soltis, Normally a lot of things are limited to limit accidents and intentional malice. Prevents full system resource starvation when a process decided to eat all file descriptors by accident or otherwise. | 05:54 |
| Soltis | I don't mean why do limits exist; that's obvious: I mean why is this limit specification in limits.conf ignored entirely? | 07:21 |
| CueXXIII | Soltis: did you set a hard or a soft limit? usually those are set via pam_limits on login, i think | 07:23 |
| Soltis | Both. | 07:23 |
| CueXXIII | hm, does ulimit -H -a show the unlimited limit? | 07:24 |
| CueXXIII | and did you login new after changing the limit conf? | 07:24 |
| gnarface | also, what release is it? i seem to recall an old old bug where limits were ignored by sshd until you touched all the files in /etc/pam.d and restarted it, or something like that... | 07:25 |
| gnarface | i thought there was also a kernel hard limit on nofiles specifically, though i'm also pretty sure it was higher than 1024 by default | 07:26 |
| CueXXIII | oh, as root i can only set ulimit -H -n 1048576 (2^20), on ulimit -H -n 1048577 or higher (or unlimited) i get: -bash: ulimit: open files: cannot modify limit: Operation not permitted | 07:29 |
| CueXXIII | so the "unlimited" gets ignored because it cannot be set | 07:30 |
| Soltis | Yeah, so I actually did get it to allow the limit of 1048576 - by setting the limit to 1048576 for root AND the other user | 07:53 |
| Soltis | (Actually, I set it to 'unlimited' for both users, which amounts to the same thing) | 07:54 |
| CueXXIII | btw. having more than 1000 open files usually is a sign of bad design, i would say | 08:13 |
| CueXXIII | you also get io buffers for each file, and checking which files are ready to read/write via select() or *poll() might use a lot of resources | 08:15 |
| gnarface | yea, and the hardware isn't really gonna be able to do "unlimited" in any practical sense | 08:33 |
| gnarface | but if you're using wine you'll run into problems at 1024 | 08:33 |
| gnarface | because windows stuff is bad | 08:33 |
| gnarface | 8192 should usually be plenty | 08:33 |
| CueXXIII | seems 8192 might be the upper limit on windows anyways… https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmaxstdio?view=msvc-170#remarks | 08:50 |
| CueXXIII | but yeah, unlimited really only means "until you run out of memory" and could even invoke the oom killer | 08:51 |
| joerg | inotify related | 12:39 |
| joerg | kicad is (has been) notorious for that | 12:39 |
| joerg | hmm, maybe only sumular, nit really related | 12:53 |
| joerg | similar* | 12:53 |
| Soltis | Larger databases can easily hit hundreds of thousands of open files. | 19:20 |
| rwp | Specialized tasks often need specialized configurations. | 19:22 |
| Soltis | I am aware of that. That's not the issue here. The issue here is limits.conf requiring the limit be raised on an unrelated user in order to achieve a task. | 19:23 |
| Soltis | That is extremely bizarre | 19:23 |
| rwp | "unrelated user"?? | 19:24 |
| Soltis | In order to raise the limit for the user I actually wanted to raise it for (mysql user) I had to set both root _and_ mysql users to unlimited in limits.conf | 19:26 |
| rwp | I think both root and mysql would be related users. | 19:26 |
| Soltis | Only if you have a singularly windows-esque notion of user rights inheritance. | 19:27 |
| rwp | Let's not get offensive here. I am not a windows user. Blech! | 19:28 |
| rwp | Off the top of my head I don't recall exactly how the flow of nofile limit is set. I look and see that it is "cat /proc/sys/fs/file-max" => 144920 on my Unstable 6.7.9-amd64 kernel. | 19:29 |
| rwp | And then that my command line shell is soft limited "ulimit -Hn" to 1024 and hard limited "ulimit -Sn" at 4096. I presume that PAM is adding those limits but not sure and don't know. | 19:30 |
| Soltis | I'm not suggesting you are, just that since Linux doesn't treat its own root user as a second-class citizen on the machine, (compare "Administrator" or even SYSTEM users on a modern Windows box) it's bizarre to cascade limits like that, unless conceptually the root user limits are a de facto way to describe inherent limits to the kernel itself (which doesn't make conceptual sense) | 19:35 |
| rwp | UID 0 root is a special user because everything starts there. Unix-like systems have a strong inheritance tree from there as PID 1 init starts as root and then init starts rc and rc starts everything else. | 19:37 |
| Soltis | Oh, I know all of that. | 19:38 |
| Soltis | I also am overwhelmingly certain I remember this kind of cascading not being a factor in the past, unless there was a *very* recent decision to change the implicit/default limits for root | 19:39 |
| rwp | Digging into this briefly it looks like pam_limits.so is what sets these limits for "logged in user sessions" which almost by definition these days passes through PAM. | 19:39 |
| Soltis | Yeah, that roughly corresponds to what I found. | 19:40 |
| rwp | Well that is totally crazy but grep'ing I find /usr/include/asm-generic/resource.h sets "#define RLIMIT_NOFILE 7" a very small number which I truly did not expect to see. | 19:43 |
| rwp | I look on my old Debian 9 Stretch system and everything is the same there as it is now on Unstable. I look on an older Debian 7 Wheezy system and it is the same there too. That's going back 10 years. So nothing seems to have changed "recently". | 19:47 |
| rwp | This is one of those fascinating problems that I wish I weren't working on other things and would chase down the rabbit hole. | 19:56 |
| rwp | But alas I must do something else now. Good luck! | 19:56 |
| Soltis | That's interesting; I can't help thinking it's originating elsewhere, but who knows? | 21:06 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!