staging.inyokaproject.org

Ein Freund benutzt auf seinem Ubuntu Server ein selbstgeschriebenes Programm, das jetzt 2x nach 18 Tagen seine Arbeit ohne erkennbaren Grund einstellte. Es besteht der Verdacht, daß dieses Programm Dateien öffnet und diese nicht wieder richtig schließt, sodaß ständig neue Datei-Handles verbraucht werden.

Ich gehe mal davon aus, daß ein Ubuntu Server nicht unendlich viele Datei-Handles gleichzeitig ermöglichen kann, sondern daß es da ein Limit gibt.

Frage1: ist es möglich abzufragen, wieviele Datei-Handles zur Zeit noch frei sind?

Frage2: ist es möglich abzufragen, wieviele Datei-Handles ein bestimmtes Programm zur Zeit geöffnet hat?

Danke im Voraus.

sysctl fs.file-nr

1. Zahl: Anzahl Datei-Handles 2. Zahl: Anzahl unbenutzte Datei-Handles 3. Zahl Systemweites Maximum an Datei-Handles

Datei-Handels für einen bestimmten Prozess. 'PID' durch Prozessnummer ersetzen:

ls -l /proc/PID/fd | wc -l

Vielen Dank Thomas für diese schnelle Antwort. Der 2. Befehl ist klar und macht, was er soll. Zum 1. Befehl habe ich noch eine Frage. Auf meinem System kommt da:

hg6@i3300:~$ sysctl fs.file-nr
fs.file-nr = 19382      0       9223372036854775807

Die 1. Zahl scheint die Anzahl Datei-Handles zu sein, die aktuell in Benutzung sind. Klar.
Wenn die 3. Zahl das Maximum der systemweiten Datei-Handles ist, wären das ja ganz schön viele.
Aber die 2. Zahl ist unklar. Du schriebst, das wären die Anzahl unbenutzte Datei-Handles. Aber diese Zahl ist immer 0. Das scheint nicht zu passen...

file-max & file-nr

The value in file-max denotes the maximum number of file- handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.

Historically,the kernel was able to allocate file handles dynamically, but not to free them again. The three values in file-nr denote the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles – this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.

Attempts to allocate more file descriptors than file-max are reported with printk, look for "VFS: file-max limit <number> reached".

¶

Hartmut2 schrieb:

Wenn die 3. Zahl das Maximum der systemweiten Datei-Handles ist, wären das ja ganz schön viele.

Das ist die größte Integerzahl die 64 Bit darstellen kann > unlimitiert. Das heißt aber nicht, dass Deine Hardware eine solche Anzahl von Handles speichern kann 😉.

Besten Dank Thomas für diese präzisen Antworten. Das Thema ist damit gelöst.

Beim rumspielen mit

ls -l /proc/PID/fd

hab ich übrigens noch was interessantes entdeckt: in der Datei

ls -l /proc/PID/fd/limits

stehen bei mir folgende Infos:

Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             30077                30077                processes
Max open files            1024                 1048576              files
Max locked memory         1000574976           1000574976           bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       30077                30077                signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

d.h. ein einzelnes Programm kann bei mir max. 1024 Dateien gleichzeitig öffnen (hab's ausprobiert und es stimmt).

Hartmut2 schrieb:

d.h. ein einzelnes Programm kann bei mir max. 1024 Dateien gleichzeitig öffnen (hab's ausprobiert und es stimmt).

Das könnte man ggf. anpassen, wenn das ursprüngliche Problem nicht durch einen Bug verursacht wird. Den müsste man natürlich beseitigen.

Hartmut2 schrieb:

Frage2: ist es möglich abzufragen, wieviele Datei-Handles ein bestimmtes Programm zur Zeit geöffnet hat?

Beispiel mit X, dem XServer, pgrep gibt die PID aus, xargs setzt sie ein im proc Verzeichnis:

pgrep X | sudo ls -l /proc/$(xargs)/fd/ | sed '1,1d' | wc -l

Wenn es keine Bash ist, die C-Shell mag Bashism nicht:

pgrep X | sudo ls -l /proc/`xargs`/fd/ | sed '1,1d' | wc -l

So lässt sich besipielsweise anschauen worauf der XServer zugreift:

pgrep X | sudo ls -l /proc/$(xargs)/fd/ | sed '1,1d' | awk '{ print $NF }'

pipe:[14844]
pipe:[14845]
socket:[16545]
socket:[15010]
/proc/mtrr
/proc/mtrr
/dev/tty1
/dev/nvidiactl
pipe:[14843]
socket:[20654]
/dev/vga_arbiter
/dev/nvidia0
pipe:[14846]
/dev/nvidia0
/dev/nvidia0
/dev/nvidia-modeset
socket:[16574]
/dev/dri/renderD128
socket:[16575]
/dev/nvidia0
/dev/nvidia0
socket:[16576]
(deleted)
anon_inode:[eventpoll]
/dev/nvidia0
/dev/nvidia0
/dev/nvidia0
/dev/nvidiactl
/dev/nvidia-modeset
/dev/nvidia0
/dev/nvidia0
pipe:[15977]
/dev/dri/renderD128
pipe:[15977]
pipe:[16542]
pipe:[15978]
pipe:[15978]
anon_inode:[eventpoll]
anon_inode:[eventpoll]
anon_inode:[timerfd]
/dev/input/event1
/dev/input/event0
/dev/input/event2
socket:[17207]
/dev/input/event4
pipe:[16542]
/dev/input/event5
/dev/input/event6
socket:[16244]
socket:[16221]
socket:[16223]
socket:[18590]
socket:[16228]
socket:[18642]
socket:[17001]
socket:[17002]
/var/log/Xorg.0.log
socket:[16272]
socket:[18206]
socket:[74956]
socket:[17048]
socket:[17050]
socket:[17054]
socket:[18699]
socket:[18374]
socket:[18376]
socket:[18380]
socket:[16543]
socket:[18884]
socket:[33955]
socket:[36120]
socket:[17301]
socket:[59458]
socket:[19027]
socket:[16544]
socket:[17494]

Danke trollsportverein für diese neuen Anregungen und vor allem auch für die Links, die mir das Verstehen, was da passiert, sehr erleichtert haben.