On Tue, Nov 20, 2018 at 09:48:27AM -0800, Daniel Colascione wrote: > On Tue, Nov 20, 2018 at 9:39 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > We have a limit on the number of FDs a process can have open for a reason. > > Well, for many reasons. > > And the typical limit is too low. (I've seen people clamp it to 1024 > for some reason.) 1024 is the soft limit. 4096 is the default hard limit. You can always ask root to set your hard limit higher if that's what you need. > A file descriptor is just a handle to a kernel > resource. All kernel resources held on behalf of applications need > *some* kind of management interface. File descriptors provide a > consistent and uniform instance of such a management interface. Unless > there's a very good reason, nobody should be using non-FD handles for > kernel resource management. A low default FD table size limit is not > an example of one of these good reasons, not when we can raise FD > table size limit. In general, the software projects should not have to > put up with ugly workarounds for limitations they impose on > themselves. I'm not really sure why you decided to go off on this rant. My point to Pavel was that there's no way a single process can tie up all of the PIDs. Unless root decided to let them shoot everybody else in the system in the foot.
