Proces limiteren op runtijd.

[Wido]

Hallo,

De topictitel is misschien niet zo duidelijk, dus laat ik het wat duidelijker uitleggen.

Via de PAM limits kan je de volgende opties opgeven:

- core - limits the core file size (KB)
- data - max data size (KB)
- fsize - maximum filesize (KB)
- memlock - max locked-in-memory address space (KB)
- nofile - max number of open files
- rss - max resident set size (KB)
- stack - max stack size (KB)
- cpu - max CPU time (MIN)
- nproc - max number of processes
- as - address space limit
- maxlogins - max number of logins for this user
- priority - the priority to run user process with
- locks - max number of file locks the user can hold

Nu kan ik dus gebruikers al limiteren op geheugen gebruik, cpu tijd, aantal processen, maar wat ik ook nog wil is een gebruiker limiteren op de tijd dat zijn proces mag draaien.

Bij webhosting heb je altijd last van die irritante botjes, je kan er van alles tegen gaan doen met mod_security, maar als ze daar eenmaal langs zijn is het vrij spel.

Nu wil ik geen discussie over botjes, maar meer over mijn aanpak.

Ik wil namelijk opgeven dat een proces van de gebruikers uit de groep "customers" niet langer dan 3600 seconde mag draaien, ofwel een uur.

Zo voorkom ik ook dat Apache processen blijven hangen of endless loops van mensen die Perl verkeerd gebruiken.

Iets zelf gaan scripten heb ik niet zo veel zin in, dat moet ook weer volledig worden gedebugged en dat kost veel tijd.

Heeft iemand een idee of zoiets bestaat? Zo ja, heb je een linkje voor me?

[gjtje]

Krijg je dan geen last mail bijvoorbeeld imap gebruikers? Dat draait ook als process onder gebruike x.

[arvid]

Ja dat kan met ulimit: http://www.ss64.com/bash/ulimit.html maar dan moeten je users wel een shell hebben. Verder zijn er wel betere methodes tegen botjes dan jouw oplossing.

Update:

Sorry verkeerd gelezen. Bij mijn weten is het limiteren op runtime onmogelijk.

[MikeN]

Erm, zelf scripten van dit is toch niet _zo_ moeilijk? Volgens mij valt het te scripten in de tijd dat je erover hebt gedaan dit topic aan te maken.

[Wido]

Krijg je dan geen last mail bijvoorbeeld imap gebruikers? Dat draait ook als process onder gebruike x.

Nee, want de servers waarop ik het ga toepassen zijn webservers.

Wij hebben alles gescheiden, webservers, mailserver, databaseservers.

Elke Vhost bij ons heeft een eigen gebruiker en draait daar ook onder.

@ arvid, tuurlijk, maar ik wil het niet alleen tegen botjes doen. Ook tegen processen van een klant die blijven hangen bijvoorbeeld.

[t.bloo]

Sinds ik laatst ook effe zo'n botje had, ben ik naar hetzelfde op zoek. Alleen wilde ik 'm handmatig afschieten na een melding (heb iets minder servers ) maar het idee is hetzelfde. Ik was tot de conclusie gekomen dat zelf scripten niet zo moeilijk is in een hogere programmeertaal. Ieder uur even een lijst met process nummers tegen een eerdere lijst aanhouden en je bent er al bijna.

[Wido]

Zelf scripten is niet zo moeilijk nee, dat klopt. Maar je moet ook uitzoeken van welke gebruiker het proces is en in welke groep die gebruiker zit.

Dat is allemaal mogelijk, maar bug gevoelig.

Daarom heb ik liever iets wat vanuit het kernel werkt, daar vertrouw ik wat meer op.

[MikeN]

Aan een simpele ls -l output van je /proc heb je al genoeg, daar staat volgens mij alle info in die je nodig hebt.... Zie de buggevoeligheid niet zo.

Volgens mij moet:

cd /proc; find * -maxdepth 1 -type d -group customers -mmin +60 -exec kill -9 {} \;

al veel doen ;p

[edit]
Eea aan inhoud van /proc lijkt wel kernel afhankelijk te zijn, 2.4.x kernel werkt het niet op, omdat timestamp van je dirs daar de huidige tijd zijn.

[Wido]

Mike, wat een super idee!

Ik had daar echt even niet aan gedacht, maar dat werkt natuurlijk prima!

Ik ga daar eens mee testen.

EDIT: ff snel getest op een 2.6 bak, werkt prima

Maar nog even wat verder tunen moet werken.

[brinkie]

Ik weet niet of het is wat je zoekt, maar zelf gebruik ik op m'n servers PRM (http://www.rfxnetworks.com/linux_appsec_prm.php) omdat natuurlijk niet alleen gebruikers wel eens een hangend proces veroorzaken.. Werkt tot nu toe perfect. Ik heb het vorig jaar in gebruik genomen, naast mod_secure, omdat één van de servers zo zwaar belast was geraakt dat die continue onderuit ging. Toen PRM draaide kon ik al snel de boosdoener onderscheppen.

[arvid]

Het constant afschieten van processen door middel van kill -9 is echt een afrader.

[Stefan Mensink]

Waarom dan arvid?

[arvid]

kill -9 is een breekijzerswitch dit zorgt ervoor dat hoe dan ook een proces wordt gekilled. Het grote nadeel hiervan is dat als je op deze manier kill gebruikt dat het proces niet netjes bij de kernel wordt afgemeld. Hierdoor kan je systeem behoorlijk instabiel worden. kill -9 moet daarom normaal gesproken pas gebruikt worden in uiterste noodzaak wanneer een proces niet meer op een normaal kill signaal reageert.

Scripts om te bereiken wat de topic starter wil zijn allemaal heel erg leuk maar zoals iemand eerder al zei zouden dit soort dingen door de kernel geregeld moeten worden en zover ik weet is dit normaal gesproken niet mogelijk. Maar de ontwikkelingen gaan hard in linux land dus wie weet

[Wido]

kill -9 is een breekijzerswitch dit zorgt ervoor dat hoe dan ook een proces wordt gekilled. Het grote nadeel hiervan is dat als je op deze manier kill gebruikt dat het proces niet netjes bij de kernel wordt afgemeld. Hierdoor kan je systeem behoorlijk instabiel worden. kill -9 moet daarom normaal gesproken pas gebruikt worden in uiterste noodzaak wanneer een proces niet meer op een normaal kill signaal reageert.

Scripts om te bereiken wat de topic starter wil zijn allemaal heel erg leuk maar zoals iemand eerder al zei zouden dit soort dingen door de kernel geregeld moeten worden en zover ik weet is dit normaal gesproken niet mogelijk. Maar de ontwikkelingen gaan hard in linux land dus wie weet

Ik (TS) was ook de gene die zei dat ik het liever vanuit het kernel zag gebeuren.

[MikeN]

Kill -9 instabiliteiten veroorzaken bij het killen van processen van gewone users? Lijkt me niet, zou ook erg onwenselijk zijn gezien dat zou betekenen dat iedere user een systeem instabiel kan maken (aangezien iedereen zijn eigen processen gewoon een KILL signal kan sturen). Het proces wordt ook netjes bij de kernel uit de process table gehaald (duh, anders zou het nog runnen) en er blijft niets in de kernel over.
Een ander verhaal is het natuurlijk wanneer processen met meer privileges hard afgeschoten worden (root processen met name), aangezien het mogelijk is dat deze bepaalde kernel calls uit hebben staan welke netjes afgerond dienen te worden, wat in het geval van een harde kill niet zal gebeuren. Maar bij gewone "customer" processen zou dit probleem niet zo moeten spelen.