Wie werden PID's vergeben?

[ingo2]

Mal eine ganz ausgefallene Frage:

Auf meinem kleinen Serverlein laufen nur wenige zusätzliche Dienste: unbound, haproxy, lighttpd, und natürlich sshd, die auch kaum genutzt werden - außer unbound. Wenn ich mir aber die Prozeßliste ansehe mit

Code: Alles auswählen

ps ax

dann laufen aktuell zwar nur 119 Prozesse, aber die PID's sind schon bald "aufgebraucht", da das Limit ja 32768 ist und ich bin schon nach kurzer Zeit (4 Tage nach Reboot) bei fast 27.000 angekommen:

Code: Alles auswählen

...
  878 ?        Ss     0:00 /usr/sbin/exim4 -bd -q30m
  883 ?        SLs    1:15 /usr/sbin/watchdog
 3072 ?        Ss     1:32 /usr/bin/python2 /usr/bin/supervisord -n -c /etc/supe
25606 ?        I      0:02 [kworker/2:0-events]
26066 ?        S      0:00 /bin/bash /usr/local/bin/monitor-log
26067 ?        S      0:00 tail -fn0 /var/log/kern.log
26068 ?        S      0:00 /bin/bash /usr/local/bin/monitor-log
26307 ?        I      0:03 [kworker/3:1-events]
26365 ?        I      0:00 [kworker/0:1-events]
26528 ?        I      0:00 [kworker/1:2-events]
26601 ?        I      0:00 [kworker/u8:0-events_unbound]
26682 ?        I      0:00 [kworker/2:2-events]
26684 ?        I      0:00 [kworker/1:0-events]
26847 ?        Ss     0:00 sshd: root@pts/0
26850 ?        Ss     0:00 /lib/systemd/systemd --user
26851 ?        S      0:00 (sd-pam)
26852 ?        I      0:00 [kworker/3:0-events]
26855 ?        I      0:00 [kworker/0:2-cgroup_destroy]
26866 pts/0    Ss     0:00 -bash
26872 ?        I      0:00 [kworker/u8:2-edac-poller]
26924 ?        I      0:00 [kworker/u8:1-events_unbound]
26935 pts/0    R+     0:00 ps ax

Muß ich da evtl. das Limit hoch setzen - ist ja ein 64-bit Buster und das sollte ja viel mehr PID's handeln können?
Oder werden die PID's nicht in aufsteigender Folge vergeben, oder werden alte recycelt?

Mein Desktop hat 182 aktive Prozesse, die höchste PID ist aber nur 6.150 - das verstehe ich nicht.

Beste Grüße,
Ingo

[MSfree]

...aber die PID's sind schon bald "aufgebraucht"

Unsinn, da wird nichts "verbraucht". Wenn der Kernel bei /proc/sys/kernel/pid_max angekommen ist, wird einfach bei 1 wieder angefangen. Sonst wären Uptimes von mehreren Jahre ja gar nicht möglich.

[Meillo]

Wenn der Kernel bei /proc/sys/kernel/pid_max angekommen ist, wird einfach bei 1 wieder angefangen.

... die naechste *freie* PID zu verwenden. (Die PID 1 gehoert init und wird demnach nie frei werden.)

Der Kernel stellt sicher, dass jeder Prozess waehrend seiner Laufzeit eine eindeutige PID hat. Nach Ende eines Prozesses kann dessen PID aber fuer einen neuen Prozess genutzt werden. Du kannst folglich, was PIDs betrifft, nicht mehr als 32k Prozesse *gleichzeitig* am Laufen haben.

[MSfree]

Du kannst folglich, was PIDs betrifft, nicht mehr als 32k Prozesse *gleichzeitig* am Laufen haben.

Wobei /proc/sys/kernel/pid_max ein beschreibbarer Kernelparameter ist, den man zur Laufzeit verändern kann. Siehe auch hier: viewtopic.php?t=177092

Wobei mehr als 32768 gleichzeitig laufende Prozesse wohl eine Seltenheit sind. Typisch snd eher 100-200 gleichzeitige Prozesse.

[Meillo]

Du kannst folglich, was PIDs betrifft, nicht mehr als 32k Prozesse *gleichzeitig* am Laufen haben.

Wobei /proc/sys/kernel/pid_max ein beschreibbarer Kernelparameter ist, den man zur Laufzeit verändern kann. Siehe auch hier: viewtopic.php?t=177092

Ah, interessant. Weisst du, ob das abgesichert ist, also dass da nicht jemand (aus Versehen) eine zu kleine Zahl reinschreibt und damit das System an die Wand faehrt?

In der Praxis wird all das kaum relevant werden. Wie du schreibst ist die uebliche Anzahl von Prozessen in ganz anderen Groessenordnungen.

[MSfree]

Weisst du, ob das abgesichert ist, also dass da nicht jemand (aus Versehen) eine zu kleine Zahl reinschreibt und damit das System an die Wand faehrt?

/proc/sys/kernel/pid_max darf nur von root beschrieben werden, alle anderen haben nur Leserecht. Das schützt allerdings nicht vor einem "Spaßvogel", der sich root-Rechte ergattert und die Zahl runtersetzt.

Was passiert, wenn man bei einem System, bei dem gerade 150 Prozesse laufen, diesen Wet auf 100 setzt, habe ich noch nicht ausprobiert.

[Meillo]

Was passiert, wenn man bei einem System, bei dem gerade 150 Prozesse laufen, diesen Wet auf 100 setzt, habe ich noch nicht ausprobiert.

Nun, wahrscheinlich habe ich etwas zu theoretisch gedacht, denn es wird unmoeglich sein, den Wert auf eine Zahl zu setzen, die kleiner als die groesste bereits vergebene aktive PID zu setzen. Das wuerde das System ja zwangslaeufig killen, also ist der Fall garantiert abgefangen. Sobald das System auch nur eine kleine Weile laeuft gibt es Prozesse, die wieder beendet sind und damit Loecher im Zahlenraum. Selbst wenn man den Wert also auf eins ueber der groessten vergebenen aktiven PID setzt, so kann man weiterhin Prozesse erzeugen. Es wird in der Praxis kaum moeglich sein, die Obergrenze weit zu druecken. Zudem koennte ich mir vorstellen, dass als Werte nur Zweierpotenzen erlaubt sind. Falls dem so ist, waere die Umsetzbarkeit eines schrittweisen Runtersetzens der Obergrenze, immer dann wenn gerade die obersten PIDs zufaellig wieder freigegeben sind, noch unwahrscheinlicher. So gesehen ist das wohl alles gar nicht praxisrelevant.

... aber man koennte auf einem Live-System ja mal damit rumspielen.

[MSfree]

... aber man koennte auf einem Live-System ja mal damit rumspielen.

Gesagt getan, ich habe hier einen Raspi, der auch abstürzen darf, ohne Schaden am Netzwerk anzurichten.

Zudem koennte ich mir vorstellen, dass als Werte nur Zweierpotenzen erlaubt sind

Nein, das habe ich gerade probiert. Ich habe da mal 24000 eingetragen, ohne Problem.

denn es wird unmoeglich sein, den Wert auf eine Zahl zu setzen, die kleiner als die groesste bereits vergebene aktive PID zu setzen. Das wuerde das System ja zwangslaeufig killen, also ist der Fall garantiert abgefangen.

Auch das habe ich gerafde probiert, die größte gerade im System vergebene PID war 23605 und gesetzt habe ich 10000, kein Absturz. Bereits laufende Prozesse behalten einfach ihre PID bei.

[ingo2]

Sorry, bin gestern leider nicht mehr dazu gekommen, eine Antwort zu schreiben.

Das mit

... pid_max angekommen ist, wird einfach bei 1 wieder angefangen.

hatte ich natürlich auch bei meinen Recherchen gefunden, erschien mir aber wenig fundiert - würde ja reboot bedeuten.

Habe zu dem Thema jetzt noch einen interessanten Beitrag gefunden: https://www.linux-magazin.de/ausgaben/2 ... n-technik/, nachdem die hohen PID's offensichtlich fast ausschließlich "kworker" Threads sind. (Vieles aus dem Beitrag ist jedoch zu hoch für mich, aber deuten auf kworker hin. Inzwischen bin ich bei PID 29749 angekommen.
Mir scheint, für die hohen PID's ist der supervisor-Daemon, mit dem ich seit Kurzem das kern.log auf einen bestimmten Fehler monitore, verantwortlich. Wie man schon im ersten Posting sieht, bewegen sich die meisten PID's im 3-stelligen Bereich, dann kommt ein Sprung auf 3072 für supervisord, dann folgen monitor-log und tail - das sind die Prozesse, die supervisord startet/überwacht - mit PID's > 26.000.

Offenbar hat sich supervisord die hohen PID's höchstpersönlich ausgesucht und die vielen kworker-Threads gehören dazu? Mal sehen, was ab 32k passiert?

Also so simpel (just round robin Vergabe) kann das auch nicht sein. Aber so, wie jetzt bei mir, müßte ja der Kernel eine riesige Tabelle mit 32k Datensätzen verwalten?

Nachtrag:
Meine Befürchtung war bisher, dass ich da irgendein Script gebastelt habe, welches sich nicht ordentlich beendet und dann jede Menge "leere" PID's oder Zombies produziert - das ist offenbar nicht der Fall.

[MSfree]

Also so simpel (just round robin Vergabe) kann das auch nicht sein. Aber so, wie jetzt bei mir, müßte ja der Kernel eine riesige Tabelle mit 32k Datensätzen verwalten?

Es wurde ja weiter oben angemerkt, daß es nicht ganz simpel Round-Robin sen kann. Es wird halt die nächste freie PID verwendet, also wenn 1 belegt ist (durch systemd oder init), dann nimmt der Kernel halt 2. Möglicherweise gruppiert der Kernel auch nach UserID oder ähnlichem. Vor einem Übrlauf brauchst du aber keine Angst zu haben, das wird auf jeden Fall richtig behandelt.

Jedenfalls ist die Prozesstabelle nicht riesig. Es wird intern nur eine 32k Pointerliste erstellt, was 256kB kostet. Pro laufendem Prozeß wird dann ein Prozeßstruktur von (keine Ahnung, vielleicht) 1kB angelegt und dem entsprechenden Pointer angehängt, was bei 200 laufenden Prozessen nochmal 200kByte kostet, zusammen also nichtmal ein halbes MB.

Wird ein Prozeß beendet, wird der Speicher der Prozeßstruktur freigegeben und der Pointer in der PID-Liste auf Null gesetzt.

[ingo2]

Vor einem Übrlauf brauchst du aber keine Angst zu haben, das wird auf jeden Fall richtig behandelt.

Na, das ist mal eine gute Nachricht
Ich bin nämlich auf der Suche nach einem ganz verflixten Fehler:

An meinem Serverlein habe ich 2 USB3.0-Ports, davon "verstopft" nach ein paar Tagen oder auch mal Wochen der Port, an dem mein RTL-SDR-Dongle hängt. Dann gibt's folgende Fehlermeldung in den Logs:

Code: Alles auswählen

apu kernel: [1456456.241467] xhci_hcd 0000:00:10.0: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
apu kernel: [1456456.241485] xhci_hcd 0000:00:10.0: ep deq seg = 00000000d1aad5e1, deq ptr = 000000002e151607

Dazu habe ich inzwischen einen Workaround gefunden, indem ich beim Auftreten der Meldung im kern.log den xHCI-Treiber kurz vom USB-Root-Hub trenne und wieder verbinde mit diesem Script:

Code: Alles auswählen

LOGFILE=/var/log/kern.log
PATTERN='Mismatch.*xHCI'
tail -fn0 $LOGFILE | \
while read line; do
    echo "$line" | grep "$PATTERN" > /dev/null
    if [ $? = 0 ]
    then
	sleep 10
	echo "0000:00:10.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
	sleep 5
	echo "0000:00:10.0" > /sys/bus/pci/drivers/xhci_hcd/bind
	echo "USB-xHCI root hub rebound" | mail -s xHCI root
    fi
done

Habe vorher schon alles Mögliche versucht, aber statt des xHCI-Treibers den EHCI-Treiber anzubinden klappt leider nicht - ohne den xHCI funktioniert auch EHCI nicht mehr.

Die wahre Ursache zu finden, ist wohl fast unmöglich, kann das Dongle sein, kann ein "fauler" USB-Port sein, kann die Firmware oder das BIOS (Coreboot + Sea-BIOS sein, ...

Und da kam mir die Beobachtung der PID's in den Sinn.

Gruß,
Ingo

[eggy]

https://git.kernel.org/pub/scm/linux/ke ... ?h=v5.6.10
falls jemand selbst nachsehn will.

/* Verify no one has done anything silly: */

die haben wohl mit $neugierigenMeillosUndCo gerechnet

Ich hätt da ja weniger Absicherung erwartet, getreu dem Motto "Bist root und solltest wissen was Du da tust. Wer sich selbst in den Fuß ballern will, soll das gefälligst machen dürfen."

Interessant wirds vielleicht, wenn man den Wert auf unter 300 setzt; ka, vielleicht auch nicht, ich habs heute nicht so mit Aussagenlogik, einfach mal ausprobieren oder 574ff lesen und selbst schauen, welche Auswirkung das haben könnte. Ich seh für pid_max nen Minumum von 301 und für pid_max_min nen Mininum vom 55, ka, ob das an anderer Stelle Auswirkungen haben kann. Oder irre ich da?

[Meillo]

https://git.kernel.org/pub/scm/linux/ke ... ?h=v5.6.10
falls jemand selbst nachsehn will.

Danke!

Ich hätt da ja weniger Absicherung erwartet, getreu dem Motto "Bist root und solltest wissen was Du da tust. Wer sich selbst in den Fuß ballern will, soll das gefälligst machen dürfen."

Ich denke, dass du diesen Spruch nicht in diesen Kontext uebertragen darfst. Das System hintert root nicht daran die Funktionen des Systems beliebig anzuwenden, aber der Kernel schuetzt sich dennoch selbst. In der ganz fruehen Zeit war das vielleicht noch nicht weit genug ausgearbeitet, aber ich frage mich trotzdem ob nicht auch im Research Unix schon verhindert war, dass man z.B. Directory-Dateien editiert (auch wenn das nicht das beste Beispiel ist). Ich denke, dass sehr klar ist, dass ein Kernel seine eigene Konsistenz sichern muss. Ob ein User seine Daten loescht oder ob er direkt auf Device-Dateien schreibt, das gefaehrdet nicht die Konsistenz des Systems. Wenn er aber den Kernel aushebeln kann, dann muss das verhindert werden.