lsof versus /proc/$PID/fd versus ulimit -n
Clash Royale CLAN TAG#URR8PPP
I am trying to find the reason why my long-running app sometimes busts the maximum open file descriptor limit (ulimit -n). I would like to periodically log how many file descriptors the app has open so that I can see when the spike occurred.
I know that lsof includes a bunch of items that are excluded from /proc/$PID/fd... Are those items relevant with regard to the open file descriptor limit? I.e. should I be logging info from lsof or from /proc/$PID/fd?
proc file-descriptors lsof
edited Feb 8 at 18:36
Serge Stroobandt
83521326
asked Feb 8 at 18:04
logideliclogidelic
1135
add a comment |
I am trying to find the reason why my long-running app sometimes busts the maximum open file descriptor limit (ulimit -n). I would like to periodically log how many file descriptors the app has open so that I can see when the spike occurred.
I know that lsof includes a bunch of items that are excluded from /proc/$PID/fd... Are those items relevant with regard to the open file descriptor limit? I.e. should I be logging info from lsof or from /proc/$PID/fd?
proc file-descriptors lsof
edited Feb 8 at 18:36
Serge Stroobandt
83521326
asked Feb 8 at 18:04
logideliclogidelic
1135
IMO they are open files...good questions nonetheless. Btw, depending on the server, it maybe be faster following the global number of open filessysctl fs.file-nr | awk ' print $3 '
– Rui F Ribeiro
Feb 8 at 18:24
add a comment |
I am trying to find the reason why my long-running app sometimes busts the maximum open file descriptor limit (ulimit -n). I would like to periodically log how many file descriptors the app has open so that I can see when the spike occurred.
I know that lsof includes a bunch of items that are excluded from /proc/$PID/fd... Are those items relevant with regard to the open file descriptor limit? I.e. should I be logging info from lsof or from /proc/$PID/fd?
proc file-descriptors lsof
edited Feb 8 at 18:36
Serge Stroobandt
83521326
asked Feb 8 at 18:04
logideliclogidelic
1135
I am trying to find the reason why my long-running app sometimes busts the maximum open file descriptor limit (ulimit -n). I would like to periodically log how many file descriptors the app has open so that I can see when the spike occurred.
I know that lsof includes a bunch of items that are excluded from /proc/$PID/fd... Are those items relevant with regard to the open file descriptor limit? I.e. should I be logging info from lsof or from /proc/$PID/fd?
proc file-descriptors lsof
proc file-descriptors lsof
edited Feb 8 at 18:36
Serge Stroobandt
83521326
asked Feb 8 at 18:04
logideliclogidelic
1135
edited Feb 8 at 18:36
Serge Stroobandt
83521326
asked Feb 8 at 18:04
logideliclogidelic
1135
edited Feb 8 at 18:36
Serge Stroobandt
83521326
edited Feb 8 at 18:36
Serge Stroobandt
83521326
edited Feb 8 at 18:36
Serge Stroobandt
83521326
83521326
asked Feb 8 at 18:04
logideliclogidelic
1135
asked Feb 8 at 18:04
logideliclogidelic
1135
asked Feb 8 at 18:04
logideliclogidelic
1135
1135
IMO they are open files...good questions nonetheless. Btw, depending on the server, it maybe be faster following the global number of open filessysctl fs.file-nr | awk ' print $3 '
– Rui F Ribeiro
Feb 8 at 18:24
add a comment |
IMO they are open files...good questions nonetheless. Btw, depending on the server, it maybe be faster following the global number of open filessysctl fs.file-nr | awk ' print $3 '
– Rui F Ribeiro
Feb 8 at 18:24
IMO they are open files...good questions nonetheless. Btw, depending on the server, it maybe be faster following the global number of open files
sysctl fs.file-nr | awk ' print $3 '– Rui F Ribeiro
Feb 8 at 18:24
IMO they are open files...good questions nonetheless. Btw, depending on the server, it maybe be faster following the global number of open files
sysctl fs.file-nr | awk ' print $3 '– Rui F Ribeiro
Feb 8 at 18:24
add a comment |
1 Answer
1
active
oldest
votes
tl;dr ls -U /proc/PID/fd | wc -l will tell you the number that should be less than ulimit -n.
/proc/PID/fd should contain all the file descriptors opened by a process, including but not limited to strange ones like epoll or inotify handles, "opaque" directory handles opened with O_PATH, handles opened with signalfd() or memfd_create(), sockets returned by accept(), etc.
I'm not a great lsof user, but lsof is getting its info from /proc, too. I don't think there's another way to get the list of the file descriptors a process has opened on Linux other than procfs, or by attaching to a process with ptrace.
Anyways, the current and root directory, mmapped files (including its own binary and dynamic libraries) and controlling terminal of a process are not counted against the limit set with ulimit -n (RLIMIT_NOFILE), and they also don't appear in /proc/PID/fd unless the process is explicitly holding open handles to them.
answered Feb 8 at 19:06
pizdelectpizdelect
66618
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499518%2flsof-versus-proc-pid-fd-versus-ulimit-n%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
tl;dr ls -U /proc/PID/fd | wc -l will tell you the number that should be less than ulimit -n.
/proc/PID/fd should contain all the file descriptors opened by a process, including but not limited to strange ones like epoll or inotify handles, "opaque" directory handles opened with O_PATH, handles opened with signalfd() or memfd_create(), sockets returned by accept(), etc.
I'm not a great lsof user, but lsof is getting its info from /proc, too. I don't think there's another way to get the list of the file descriptors a process has opened on Linux other than procfs, or by attaching to a process with ptrace.
Anyways, the current and root directory, mmapped files (including its own binary and dynamic libraries) and controlling terminal of a process are not counted against the limit set with ulimit -n (RLIMIT_NOFILE), and they also don't appear in /proc/PID/fd unless the process is explicitly holding open handles to them.
answered Feb 8 at 19:06
pizdelectpizdelect
66618
add a comment |
tl;dr ls -U /proc/PID/fd | wc -l will tell you the number that should be less than ulimit -n.
/proc/PID/fd should contain all the file descriptors opened by a process, including but not limited to strange ones like epoll or inotify handles, "opaque" directory handles opened with O_PATH, handles opened with signalfd() or memfd_create(), sockets returned by accept(), etc.
I'm not a great lsof user, but lsof is getting its info from /proc, too. I don't think there's another way to get the list of the file descriptors a process has opened on Linux other than procfs, or by attaching to a process with ptrace.
Anyways, the current and root directory, mmapped files (including its own binary and dynamic libraries) and controlling terminal of a process are not counted against the limit set with ulimit -n (RLIMIT_NOFILE), and they also don't appear in /proc/PID/fd unless the process is explicitly holding open handles to them.
answered Feb 8 at 19:06
pizdelectpizdelect
66618
add a comment |
tl;dr ls -U /proc/PID/fd | wc -l will tell you the number that should be less than ulimit -n.
/proc/PID/fd should contain all the file descriptors opened by a process, including but not limited to strange ones like epoll or inotify handles, "opaque" directory handles opened with O_PATH, handles opened with signalfd() or memfd_create(), sockets returned by accept(), etc.
I'm not a great lsof user, but lsof is getting its info from /proc, too. I don't think there's another way to get the list of the file descriptors a process has opened on Linux other than procfs, or by attaching to a process with ptrace.
Anyways, the current and root directory, mmapped files (including its own binary and dynamic libraries) and controlling terminal of a process are not counted against the limit set with ulimit -n (RLIMIT_NOFILE), and they also don't appear in /proc/PID/fd unless the process is explicitly holding open handles to them.
answered Feb 8 at 19:06
pizdelectpizdelect
66618
tl;dr ls -U /proc/PID/fd | wc -l will tell you the number that should be less than ulimit -n.
/proc/PID/fd should contain all the file descriptors opened by a process, including but not limited to strange ones like epoll or inotify handles, "opaque" directory handles opened with O_PATH, handles opened with signalfd() or memfd_create(), sockets returned by accept(), etc.
I'm not a great lsof user, but lsof is getting its info from /proc, too. I don't think there's another way to get the list of the file descriptors a process has opened on Linux other than procfs, or by attaching to a process with ptrace.
Anyways, the current and root directory, mmapped files (including its own binary and dynamic libraries) and controlling terminal of a process are not counted against the limit set with ulimit -n (RLIMIT_NOFILE), and they also don't appear in /proc/PID/fd unless the process is explicitly holding open handles to them.
answered Feb 8 at 19:06
pizdelectpizdelect
66618
edited Feb 8 at 20:39
answered Feb 8 at 19:06
pizdelectpizdelect
66618
answered Feb 8 at 19:06
pizdelectpizdelect
66618
answered Feb 8 at 19:06
pizdelectpizdelect
66618
66618
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499518%2flsof-versus-proc-pid-fd-versus-ulimit-n%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
IMO they are open files...good questions nonetheless. Btw, depending on the server, it maybe be faster following the global number of open files
sysctl fs.file-nr | awk ' print $3 '– Rui F Ribeiro
Feb 8 at 18:24