permanens ulimit apache

Linux-kezdő

echo "ulimit -n 10240" >> /etc/init.d/apache2
sync
reboot

##############################

de reboot után maradt az 1024

de kiprobaltam, hogy:

##############################

echo -e '#!/bin/bash\n\nulimit -n 10240' > /etc/init.d/ulimit-beallit.sh
chmod +x /etc/init.d/ulimit-beallit.sh
ln -s /etc/init.d/ulimit-beallit.sh /etc/rc2.d/S89ulimit-beallit
sync
reboot

##############################

de még mindig 1024

##############################

a limits.conf-ot módosítottam:

echo -e "@www-data\tsoft\tnofile\t10240\n@www-data\thard\tnofile\t10240" >> /etc/security/limits.conf
sync
reboot

még mindig 1024, még ha:

# su www-data
# ulimit -n
1024

-t adok is ki

##############################

hogyan lehet beállítani, hogy reboot után is megmaradjon az "ulimit -n 10240" eredménye? :O

  • 3585 megtekintés

( zsirmo v | 2010. 01. 05., k – 14:19 )

Szia!

/etc/security/limits.conf

itt user-hez tudsz megadni limiteket.

amit legeloszor irtal nem biztos hogy mukodik, mert ubuntu init script peldaul exit-tel, ha miutan elindult, tehat vegre sem hajtja a parancsod
raadasul, mivel a parancsot a script vegere irtad be (>> ugye) elindul az apache es utanna allitod at a limitet

( gbor | 2010. 01. 05., k – 17:49 )

1 - limits.conf-ot próbáltam már, mint ahogy írtam, sajnos nem ment :D
2 - ha letrehozok vim-el egy filet, amibe azt irom, hogy:

#!/bin/bash

ulimit -n 10240

akkor a scripten belül még 10240 lesz az ulimit, de ha lefut, akkor visszaáll 1024-re....

3 - viszont az működik, hogy:

#!/bin/bash

echo '
ulimit -n 10240
' >> /etc/profile

:D ... nem okoz ez gondot, hogy minden egyes login esetén lefut az ulimit?? :D

Lenny

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

( gbor | 2010. 01. 05., k – 17:53 )

sysctl-t nem találtam erre, van? :O

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

( petykooo | 2010. 01. 05., k – 18:02 )

man ulimit

tobbet nem is kene mondanom, de szerencsed van, ma jo napom van

ketfele limit letezik

- hard
- soft

a mezei opciokkal (pl.: -n) CSAK a soft limitet tudod allitani a hard limitig

a problema valoszinuleg az, hogy a hardlimited IS 1024.

ulimit -Ha

^ kilistazza a hardlimiteket

ulimit -Sa

^ kilistazza a softlimiteket

Celszeruen kelloen magasra KELL allitani a hard limitet (csak reboot utan all be), utana a softlimitet a juzer maga tudja allitani az ulimit parancssal a hardlimitig. 


# man ulimit
No manual entry for ulimit
# help ulimit
ulimit: ulimit [-SHacdfilmnpqstuvx] [limit]
    Ulimit provides control over the resources available to processes
    started by the shell, on systems that allow such control.  If an
    option is given, it is interpreted as follows:
    
        -S	use the `soft' resource limit
        -H	use the `hard' resource limit
        -a	all current limits are reported
        -c	the maximum size of core files created
        -d	the maximum size of a process's data segment
        -e	the maximum scheduling priority (`nice')
        -f	the maximum size of files written by the shell and its children
        -i	the maximum number of pending signals
        -l	the maximum size a process may lock into memory
        -m	the maximum resident set size
        -n	the maximum number of open file descriptors
        -p	the pipe buffer size
        -q	the maximum number of bytes in POSIX message queues
        -r	the maximum real-time scheduling priority
        -s	the maximum stack size
        -t	the maximum amount of cpu time in seconds
        -u	the maximum number of user processes
        -v	the size of virtual memory
        -x	the maximum number of file locks
    
    If LIMIT is given, it is the new value of the specified resource;
    the special LIMIT values `soft', `hard', and `unlimited' stand for
    the current soft limit, the current hard limit, and no limit, respectively.
    Otherwise, the current value of the specified resource is printed.
    If no option is given, then -f is assumed.  Values are in 1024-byte
    increments, except for -t, which is in seconds, -p, which is in
    increments of 512 bytes, and -u, which is an unscaled number of
    processes.
# ulimit -n 10240
# ulimit -Hn
10240
# ulimit -Sn
10240

ugyan úgy létrehoztam egy rövid scriptet:

#!/bin/bash
ulimit -Hn 10500
ulimit -Sn 10000

lefuttattam, de nálam nem lett eredménye, beraktam az előbbi két sort a /etc/init.d/apache2 elejére [a "#!/bin/bash -e" után rögtön] sync, reboot, de ugyan úgy 1024 volt

idáig a /etc/profile-ba való "ulimit -n 10240" működik, csak nem okoz-e ez teljesítménybeli problémát, hogy elvileg minden loginkor lefut ez az egy sor

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

( turul16 v | 2010. 01. 05., k – 18:48 )

root user limitje ne legyen kisebb IMHO. A su/sudozo usere -se.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( gbor | 2010. 01. 26., k – 16:57 )

végül:

echo -e '\nulimit -n 10240\n' >> /etc/profile

mert egy idő után mindig visszaállt.

most figyelem, hogy okoz-e plusz terhelést

fontos lenne, ha valaki tudná rá esetleg a megoldást: "Ulimitet hogyan lehet permanensen beállítani?" - az apache internal server error 500-akat dobál egy pár weboldalra, ha nincs beállítva 10240-re 1024-ről.

köszi

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

az a limit, amit át szeretnél állítani, az egy per-processz limit, ami a szülő processztől öröklődik.
az ulimit parancs az aktuális processzben állítja át, ill. minden ebből indított új gyerek már az új limitet fogja megörökölni.

az apache-ot egy init.d script indítja, ami - ha nem éppen kézzel segítesz neki - automatikusan indul a gép indításakor. ilyenkor az /sbin/init futtatja az rc scripteket sorban. ahhoz, hogy az apache más limittel induljon, vagy az /sbin/init-et kell átírni (ez nyilván nem játszik), vagy valamelyik shell scriptet, ami automatikusan indul.

sem a /etc/profile, sem /etc/limits.conf nem segít ilyenkor, mivel ezeket senki nem olvassa egy automatikusan induló daemon esetében (a /etc/limits.conf-ot a /bin/login ill. a pam_limits modul olvassa, a /etc/profile-t pedig a login shell futtatja).

az automatikusan induló shell scriptek közül alapvetően az apache-ot beindító (valószínűleg /etc/init.d/apache2 nevű) script a legtutibb helye ennek a beállításnak; mivel ennek a gyereke lesz a daemon, így onnan fogja örökölni a limitet.

lényeges, amit mások is írtak, hogy a soft limitet csak a hard limitig lehet növelni, tehát előbb a hard limitet (ulimit -Hn) kell kell megemelni, aztán jöhet a soft limit.

wow, köszi, már világosabb.

csak annyi a baj, hogy kipróbáltam: a "/etc/init.d/apache2"-be beleírtam [15. sorába, Lenny] azt, hogy:

ulimit -Hn 10240
ulimit -Sn 10240

de még nem működött.

szóval az lenne a lényeg, hogy boot közben minél előbb kiadja az ember ezt a parancsot, hogy aztán örökölhető legyen? ok:

echo -e '#!/bin/bash\n\nulimit -Hn 10240\nulimit -Sn 10240' > /etc/init.d/ulimit-beallit.sh
chmod +x /etc/init.d/ulimit-beallit.sh
ln -s /etc/init.d/ulimit-beallit.sh /etc/rc2.d/S20ulimit-beallit
sync
reboot

de így sem jó.

szóval mivel nem talál az ember konkrétan olyat a gugli nem 1 perces turkálása után, hogyan lehet ezt beállítani, gyanítom, hogy nem lehet beállítani. mármint konzerv kernellel. eleve megnövelt ulimit-el kell forgatni?? :D

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

csak annyi a baj, hogy kipróbáltam: a "/etc/init.d/apache2"-be beleírtam [15. sorába, Lenny] azt, hogy:

ulimit -Hn 10240
ulimit -Sn 10240

de még nem működött.

nekem meg műxik így.
tehát oda, ahol indítaná be az apache binárist, na közvetlenül az elé rakd be abba az init scriptbe.

nálam pl. ezzel megy:

start() {
checkconfig || return 1

[ -f /var/log/apache2/ssl_scache ] && rm /var/log/apache2/ssl_scache

ebegin "Starting ${SVCNAME}"
ulimit -Hn 10240
ulimit -Sn 10240
${APACHE2} ${APACHE2_OPTS} -k start

szóval az lenne a lényeg, hogy boot közben minél előbb kiadja az ember ezt a parancsot, hogy aztán örökölhető legyen? ok:

örökölni csak azok a programok tudnak bármit is, amik ugyanabból a scriptből indulnak.

tehát amikor elindul a /etc/init.d/apache2, az egy önálló programként fut. ha ebben az scriptben beállítasz valamit, az erre az egy szem programra lesz érvényes, ha ez a program a script futtatása közben beindít egy másik programot (esetünkben az apache binárist), az megörökli ettől a script futtató programtól mint szülőtől a beállítást.
egyébként amikor a script véget ér, akkor az a program is kilép, ami a scriptet futtatta. tehát csak az apache binárisa fogja megörökölni a beállítást, más nem.

virtuális gépen kipróbáltam, tök jól működött :)

már csak annyi van, hogy a serveren nem tudtam letesztelni, mert ott nincs "/proc/$apachepid/limits"?

másik mód létezik arra, hogy leellenőrizze az ember, hogy tényleg jó-e az ulimit?

köszi! :)

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

( janoszen v | 2010. 01. 27., sze – 19:58 )

Felhívnám a figyelmet arra, hogy a setrlimit() syscall doksija szerint a limit egy processzre vonatkozik. Ergó ha prefork MPM-et használsz, akkor kár a gőzért, minden processz külön limitet kap. A Linux kernelben legjobb tudomásom szerint nincs megoldás arra, hogy egy felhasználó összes processzére mondjunk szabályokat. Talán (nagyon talán) a grsecben van ilyesmi. Legalábbis ez az én értelmezésem.

A másik, hogy tök jó a limits.conf hackelése, azonban az csak akkor fog érvényre lépni, ha az alkalmazás www-data-ként nyit egy új PAM sessiont, valamint a pam sessionben be is van konfigurálva a limitek érvényre juttatása. 99%, hogy az Apache induláskor NEM nyit PAM sessiont.

Erre az igazán korrekt megoldás az volna, hogy ha valaki a RLimitMEM, RLimitCPU és az RLimitNPROC mellé megírná ezt is az Apachehoz. Elnézve az Apache forrását, ez kb 1-2 óra valakinek, aki látott már C kódot. Ha egyszer megint föltákolok egy Apache dev környezetet a gépemre, akkor lehet, megírom.

Ellenben jönne egy visszakérdés: miért is szeretnél Te ilyen limitet tenni az Apachera?

halkabban, meg ne tudják az apacs szervereim, hogy nekik nem szabad magasabb ulimiten menniük...

ha az a processz, amelyik minden apacs ősét indítani fogja a gépben, magasabb limittel megy, akkor ezt fogja örökölni minden gyerekprocessz is, még az is, amelyik az mpm forkerből indul.

gep:~# ulimit -n
1024
gep:~# su - www-data
www-data@gep:~$ ulimit -n
1024
www-data@gep:~$ logout
gep:~# ulimit -n 32000
gep:~# su - www-data
www-data@gep:~$ ulimit -n
32000

( janoszen v | 2010. 01. 27., sze – 23:22 )

Nos, foglalkoztam egy kicsit a problémával. Szültetett egy patch az Ubuntus 2.2.12-es Apache forrásra, ami hivatott lenne bevezetni az RLimitNOFILE direktívát. A patch ihun: http://hup.pastebin.com/f12367361

Jön azonban a feketeleves. Úgy tűnik, az Ubuntus forrásban egyetlen RLimit* direktíva sem működik ( https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/394350 ) és úgy tűnik, nem is nagyon tudják, mitévőek legyenek. Mivel ez a hiba nálam is jelentkezik, nem nagyon tudtam kidebuggolni. Ha valaki kicsit megsegítene egy másik rendszer alól, az sokat javítana a helyzeten.

Elvileg ugyanazt csinálja, mint a limits.conf-ban a file descriptor limit állítása, csak Apache direktíva formájában. Ha működne, a config fileban megadott RLimitNOFILE értéket állítaná be.

Közben erőlködöm a Debianos build rendszerrel de nagyon nem akar kézre állni.

Patch megtanít olvasni?
vagy mit tud? felismerteti végre a kérdésfeltevővel, hogy elhangzott itt a jó válasz?

húzzunk már egy rohadtul éles határvonalat aközé, hogy ki mit tud megcsinálni, meg aközé, hogy valójában mit hogy kell megcsinálni.

Szerk: azt mit meg azt minek, hogy standard unixos eszközökkel a problémája megoldható. Meg is kapta rá itt a megoldást, sőt, magyarázatokat is, az én számításaim szerint 3 alkalommal. Milyen patchet kell faragni egy olyan problémára, aminek egy darab shell utasítás a megoldása?

Komolyan nem értem, nézek itt bambán...

Ha offtopicnak érzed, akkor szívesen beteszem más témába. Az én részemről pusztán némi intellektuális kihívás keresés volt, mert jelenleg begipszelt lábbal rohadok otthon és muszáj valamit csinálnom. De én kérek elnézést, azt hittem, lehet belőle valami hasznos is.

A probléma az, hogy az init scripteket a disztrót gyártják, avagy ha legközelebb frissítesz, lehet hogy agyoncsapja Neked. A tiszta megoldás az lenne, ha lenne ilyen Apache fícsör és az upstreambe bekerülne.

Gyakorlati megvalósításban egy egy miniatűr modul is tudna lenni, ami semmi mást nem csinál, mint az init részben belövi a LIMIT_NOFILE-t. Ha lesz ingerenciám rá, lehet, hogy megírom. Akar valaki tesztelni?

Kérdés, kinek KISS. Ha van ilyen fícsör az Apacsban, akkor az hány munkaórát spórol meg vs mennyiben került kifejleszteni. Ez esetben egyékbént igazad lehet, mert itt most látom először a kérdést. Azért ha harmadszor látom a kérdést, akkor valszeg mégiscsak megírom a modult.

( mn3monic v | 2010. 01. 28., cs – 20:13 )

[20:11] [0:websrv2] ~ # ulimit -n
1024
[20:11] [0:websrv2] ~ # wget -q -O- http://control2/ulimit.php
user:
www-data
ulimit -n:
1024
[20:11] [0:websrv2] ~ # /etc/init.d/apache2 stop
Stopping web server: apache2 ... waiting .
[20:11] [0:websrv2] ~ # sed -i '/$APACHE2CTL start/s/\(.*\)/\t\tulimit\ -n\ 2048\n\1/' /etc/init.d/apache2
[20:11] [0:websrv2] ~ # /etc/init.d/apache2 start
Starting web server: apache2.
[20:11] [0:websrv2] ~ # wget -q -O- http://control2/ulimit.php
user:
www-data
ulimit -n:
2048
[20:11] [0:websrv2] ~ # ulimit -n
1024
[20:12] [0:websrv2] ~ # cat /var/www/control2/ulimit.php 
<?php

echo "user:\n";
system("whoami");

echo "ulimit -n:\n";
system("ulimit -n");

?>
[20:12] [0:websrv2] ~ #

Nem értem mi a probléma.

( gbor | 2010. 01. 28., cs – 21:38 )

imádom az oss-t :)
és a közösséget ami hozzá tartozik :)

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

( hrgy84 | 2010. 02. 02., k – 23:13 )

Sracok, jelentkezzen kezletoresre mindenki, aki init.d scriptet piszkit egy debian alapu rendszeren. A /etc/default/apache2 fajlba ha beleirjuk a megfelelo direktivat (jelen esetben az ulimit nevu parancsot jol felparameterezve) akkor jo lesz mindenkinek. Bar a debian amugy is a ganyolas disztroja, vannak dolgok, amikre azert van (a korulmenyekhez kepest) elegans megoldas.

Ezzel egyutt egyetertek janoszen-nel, hogy a legjobb megoldas egy Apache direktiva lenne.

[i]PS: azert mennyire vicces mar, hogy a debian a /etc/default alatti fajlokat nem konfigkent tolti be, hanem csak be source-olja a scriptekbe, mindenfele QA ellenorzes nelkul.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

azert mennyire vicces mar, hogy a debian a /etc/default alatti fajlokat nem konfigkent tolti be, hanem csak be source-olja a scriptekbe, mindenfele QA ellenorzes nelkul.

ez nem vicces, ez a legegyszerűbb módja annak, hogy könnyen lehessen bővíteni/customizálni a scripteket. így pl. bármilyen függvényt bele tudsz rakni.
ha konfig fájl lenne, akkor bazi nagy parsert kéne írni hozzá, hogy ilyeneket is tudjon. bazi nagy parsert meg nem sh-ban írunk.

bazi nagy parser? LOL. Szerinted egy key=value ertekadashoz mekkora parser kell? A sed validacio a legrosszabb esetben is ket sor.

Amugy miert kell boviteni az init scripteket? A debian nem jo init scripteket ir? Fura.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

lol.
egyik hsz-edben elmagyarázod, hogy név=érték jellegű fájl kellene, hogy legyen a /etc/default/apache2, másik hsz-edben meg tökönszúrod az egész elképzelést. akkor most döntsd el, hogy melyiket is akarod.

A debian a gányolás disztrója, rotfl. azért tudnék mondani nem egyet, nem kettőt, amelyikben több a gányolás. Igazából csak olyat tudnék mondani, amiben több.

Apacs direktíva? Mire? Arra, ami nem végrehajtható egy user programból? Arra is apacs direktívát akarsz, hogy mondjon le a kormány, vagy mire? Az apacs konfigban olyan direktívák legyenek, amik az apacshoz tartoznak. A fájldeszkriptortábla mérete az nem az apacs dolga.

A linux felhasználóbarát, nem idióta barát és nem közönyös barát. Ezt akartad, hát nesze. Ha te el akarod tolni az apacs konfigodat, told el. A te dolgod. Ez nem windows, hogy csillió wizard segítsen helyrerakni az elcseszett dolgokat. Itt ha elcseszted, akkor pont. Pont, mint a sebész, az a rendes orvos. Ha levágta, akkor levágta. (C) Hofi.

Ui: még mindig röhögök az egyik korábbi topicban a windows group policy-s hozzászólástól...

A windows fanok nem fognak röhögni rajta.. kb arról volt benne szó, hogy milyen jó a group policy, mert van benne olyan lehetőség, hogy amit a kliensen a rendszergazda elgányolt, azt a group policy helyrerakja.

Ami azért rotfl, mert nem abba fektettek erőforrást, hogy ne lehessen a klienst gányolni, hanem abba, hogy egyszerű legyen helyrerakni. A lónak a menetiránya piszkosul nem stimmel:P

A szabályozások erősorrendje teljesen jó: a gp a local admin fölé van rendelve alapértelmezetten, azaz a local admin nem túrhatja szét permanensen a központilag kikényszerítésre kerülő beállításokat. Átmenetileg igen (feltételezzük róla, hogy azért local admin,mert tudja, hogy mit csinál), de ha elbacarintja, akkor visszaáll a rend.

Azt, amit ezzel a group policyvel erőltet az ms, unixon régen meg lehetett csinálni triválisan. Láttam rá jól működő példát. Ott nem volt ilyen, hogy fájlokat elbarmolhat bárki is.

Userek NIS/YP-be, home könyvtárak nfs-en, telepített programok szintén nfs-ről, oszt jónapot. Minden ment, mint a karikacsapás.

Ha már nis, akkor legalább nis+, bár a group policy-t hozzá hasonlítani... Időben sem állnak közel egymáshoz, nem még tudásban... A UNIX-os alkalmazások filozófiája sem olyan, hogy egyszerűen meg lehetne oldani a GP-s dolgokat -- egy szimpla környezeti változóból olvasott paraméter esetén hogy oldod meg azt, hogy az user ne tudja elbarmolni?

miért, group policy alatt se tudod megoldani... fentiek szerint az arra való, hogy hagyjuk, hogy az user elbarmolja, de utána nagyon gyorsan vissza tudjuk állítani.

ha úgy hasonlítod össze a nis+-t meg az active directoryt, hogy melyik mit tud, akkor a nis+ veszít. Ha a komplett rendszert hasonlítod össze, hogy melyikkel lehet rendes üzemeltetési környezetet létrehozni, akkor egyáltalán nincs hátrányban a unixos megoldás. a group policy egy csomó olyan problémára ad megoldást, ami rendes környezetben nem merül fel. Ennyivel tud többet.

Persze tisztan UNIX kornyezetben eleg nehez definialni egy olyan fogalmat mint normalis kozponti authentikalas, meg role-based permissions, vagyis amikor nem attol lesz valaki atyauristen, hogy 0-s a UID-ja, hanem mert erre jogot kap. Eleve, UNIX-on mar a fajljogok a vicc kategoriajaba esnek... meg a tobbi is.

Tessek mar vegre megerteni, hogy az UNIX-os filozofia tobb evtizedes elmaradasban van. Meg abbol az idobol szarmazik, amikor volt 1 Gep, meg voltak a kis terminalok, akik bejelentkeztek a Nagy Gepre. Ott senkinek sem hianyzott a kozponti authentikalas illetoleg egyaltalan barmifele kozpontisag, hiszen gyakorlatilag egyetlenegy gep volt a rendszerben, tobbel nem kellett foglalkozni.

A NIS-t egy olyan rendszernek erzem, amit az ido valtozasa kenyszeritett ki. Amikor elkezdett tobb gep lenni, rajottek, hogy az 1 gepen tarolt passwd/shadow/group allomany kurva keves, es kibovitettek ugy, hogy gyakorlatilag megosztottak ezeket a fajlokat, kozkinccse teve oket. Meg elkezdodtek a kinlodasok. Az a szerencse, hogy az LDAP a vegen teljesen kiszoritotta a NIS-t.

De itt es most abba kellene hagyni a hasonlitgatast, fokepp azert mert a NIS qva sok mindent nem tud, tehat az alma meg a korte osszehasonlitasat akarod itt eroltetni. Marpedig az almat meg a kortet nem lehet osszehasonlitani.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Úgy látom, a ló feje mögötted van... (=fordítva ülsz a lovon).
Egyáltalán senkit nem érdekel, legalábbis engem biztosan nem, hogy a nis+ tud-e többet, vagy a gp. Engem kizárólag az érdekel, hogy meg lehet-e oldani a problémát az adott eszközzel, vagy sem.

A local admin meg local root egy szemléletbeli probléma: ha én felelek egy gép működéséért, akkor én vagyok rajta a rendszergazda, nevezzenek akár rootnak, akár adminnak. Mindenki másnak coki. Ha más local admin rajta, akkor magára vessen. Itt nyilván nem steve blood jáccósgépéről van szó, hanem egy céges rendszerről, ahol számít a rendelkezésre állás.

A gp azzal, hogy egy halom problémára ad megoldást, ami rendes környezetben fel sem merül, nem lesz használhatóbb, mint a nis+. A bloatedware jó kifejezés erre. Egyre gyakrabban érzem azt, hogy csak azért használnak emberek cuccokat, mert az a cucc létezik, esetleg trendi neve van.

Alma-körte: nekem a nis+ olyan, mint a lotus super7. Nincs benne semmi, de megy, mint a rakéta, el lehet vele jutni a-ból b-be (bár nem erre találták ki), és versenypályán sem vall szégyent (sőt). Ehhez képest az active directory meg olyan, mint egy merci 600 sel, kell bele egy 6 literes v12-es motor, hogy azt a böszme dobozt mozgassa, automata váltó kell bele, mert átlag béna sofőrre nem lehet rábízni 450nm nyomaték kuplungolását, szervó kormány kell bele, mert egy tonnánál nagyobb a tömeg az első tengelyen, de 255-ös gumi kell rá, mert nehéz az egész, de kell hozzá blokkolásgátló is, mert nem tud nélküle megállni a sofőr, meg távolságtartó tempomat, meg vészfékasszisztens, meg elektronikus fékerő elosztó meg elektronikusan szimulált differenciálmű meg 42 féle egyéb elektronika kezdve attól, hogy helyetted megdugja a titkárnőt a jobbegyben.

Holott ha egyszerű lenne az autó és tudnád kezelni, akkor elég a super7 is.

Csak felenken megkerdezem: ezek szerint a NIS-hez nem kell hozzaertes? Csak az AD-hoz? Mintha ez sejlene fel halvanyan a szavaid mogott... Merthogy hozzaertessel minden megoldhato, meg a GP is elkerulheto, ha valakinek hanyingere van tole. Csak tudod, a hozzaerto rendszergazda nem terem minden bokorban.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( bartamate | 2010. 02. 06., szo – 02:06 )

nekem a /etc/security/limits.conf -ban van beállítva és tökéletesen működik

"

* soft nofile 10240
* hard nofile 10240

"

Amíg nem így volt beállítva aszem az "ulimit -SHn 10240" -val lőttem be induláskor, és azzal is frankó volt.

( Celtic v | 2012. 10. 29., h – 11:13 )

Csaxolok:
- centos 5 es 6. apache, php fastcgi-kent fut. Szinten probalkoztam az /etc/security/limits.d alatt, usernek kulon file, ha shellbol lepett be, mukodott, a fastcgi ra sem pipalt.
- probaltam a wrapper scriptben allitani, nulla eredmeny
- vegul az /etc/init.d/httpd alatt allitottam be jo magasat, igy mar _kisebb_ adhato a wrapper scriptben is.

Tehat tenyleg ugy orokolte, hiaba fut a wrapper script az user neveben, az apachetol orokolte a limiteket.

--
http://www.micros~1