Julkul med Linux

När julskinkan var klar och allt annat runt också var klart, så satte
jag mig ner med en 6:a whisky framför linuxburken.

En nyinstallation av Kubuntu blev offret.

Började göra ett litet test med min användare, för att se
vad som har hänt senaste åren med kärnan sen sist jag provade detta.
Slängde iväg följande kommando:

Efter ett tag flippa kärnan ur och kunde inte skapa fler kataloger.

Kärnan fick nog efter 629 kataloger i filstrukturen. Varför jag fick 629 kataloger vet jag inte (har inte orkat undersöka). En sak vet jag däremot och det är att man kunde få skapa betydligt mer kataloger med tidigare versioner av kärnan.

Det som var intressant var att jobba i en katalogstruktur 629 kataloger ner i strukturen gjorde det väldigt trögt. Man kan säga att det kändes som en laggande uppkoppling, trots att när man körde enkla kommadon som "ls" uppfattades tröga och då var katalogen dessutom tom på data.

Sen testade jag en gammal beprövad "fork" som ger kärnan ett frispel.
Ärligt talat trodde jag inte att detta skulle funka, trodde helt enkelt att
problemet är löst sen länge.
Med följande kommando hängde sig min kubuntu-dist totalt och jag fick göra en kallstart för att komma på rätt köl igen.
Kommandot är

nice
vilket filsystem är det är det du kört "fantom-bomben" på?
ffs under openbsd4.2 började bli segt på att skapa nya mappar efter 1540 stycken, ls/touch/rm/osv var dock inga problem.
jfs på linux2.6.21.5 är dock still going strong med 15 mappar/sekund och passerade just 7000 nivåer, filoperationer är ej heller där något problem..

forkbomben däremot har jag ingen slackwarebox som jag är villig att köra på, då jag är rätt säker på att den skulle tvinga fram en hård-reboot. openbsd var dock inga problem att bara ssh:a in till och döda skalet efter ett par minuter då jag tyckte att det fick räcka.

(du saknar dock ett : i slutet på forkbomben för att faktiskt köra igång den.)

Du har rätt, missade kolon i koden för forkbomben, kan ha blivit påverkad av whiskyn

Hur som helst, så gjordes testet på ext3 som filsystem.

Du säger att jfs tuggar på fint, men är det jfs eller jfs2?
Lite förvånad isf att jfs (äldre versionen) fixar detta så bra?

Lite noggrannare undersökning visar att det är bash-skalet som suger.
Installerade ksh och kunde skapa hur mycket som helst.
Avbröt själv efter 20272 kataloger med ksh.

Man kan ju lätt stoppa en forkbomb genom att lägga in lämpliga begränsningar av antalet processer som en grupp eller användare får starta, i limits.conf.

Då blir det väl upp till mig att testa med csh!

Vilket dock förutsätter att man gett upp allt hopp om säkerhet och använder PAM..

limits.conf finns oavsätt om du använder PAM eller inte.

echo "* nproc 1024" >> limits.conf

Fungerar på Slackware, och det använder inte PAM.

limits.conf finns inte med i slackware.
curl -s ftp://ftp.sunet.se/pub/Linux/distributions/slackware/slackware-12.0/slackware/MANIFEST.bz2|bunzip2|grep limits.conf

har man installerat dropline-gnome på slackware (och därmed även pam) så bör man ha /etc/security/limits.conf (då den filen är en del av pam-paketet som ingår i dropline)

Det har du rätt i. I slackware heter den bara "limits", om jag inte minns fel. /etc/limits kanske? Hart inte kört Slackware på några år, men jag vet att filen finns och fungerar. Möjligt att du måste skapa den själv.

De inställningar du konfigurerar i denna fil är inget specifikt för PAM, utan per-process inställningar som hanteras av kernelen.