Dotaz: Zaplneny /tmp

[Petr]

Přílohy:

• df (539 bytů)
• fstab (684 bytů)

Ahoj, mam nainstalovan Arch a trochu se potykam s jednim problemem a sice ze system mi pro /tmp alokuje natvrdo jen 1G mista, coz v pripade ze kompiluji neco vetsiho z Auru ale i v jinych situacich - rychle se zaplni, kompilace zhavaruje a problem pak maji i jine aplikace ktere si do /tmp prubezne odkladaji a davaji hlasky typu "cannot create temp file for here-document: No space left on device ". Pritom disk jsem rozdelil jen na /boot, /home, /encrypted, / a swap a tedy /tmp by melo brat z / kde je mista az moc, nicmene se tak nedeje, proc a co tedy s tim delat?

---

---

Odpovědi

[k3dAR]

jak vidis z df, tak na /tmp mas namontovane tmpfs, tedy neuklada se na hdd/ssd ale do RAM, podekuj sYsTeMd ktere toto dela prehnanou aktivitou i presto ze ve fstab na to nemas zadnou pridanou polozku ;)
tuto featuru zrusis (a bude se pak tedy pro /tmp pouzivat hdd/ssd) pomoci(vice inforaci viz ArchWiki):

systemctl mask tmp.mount

[MadCatX]

fstab taky tohle mapování řešit nemá, stav všech mountpointů se má zjišťovat pomocí mount. Navíc to nedělá sám systemd sám o sobě, ale ten unit tmp.mount. Že to je na Archu výchozí nastavení je věc distribuce.

[chrono]

Je to štandardné nastavenie SystemD.

[k3dAR]

fstab tmpfs resil nez prisel systemd a rekl ze se to tak nema protoze on to dela sam a jinak a basta ;)
a stav mountpointu ne ma, ale se muze zjistovat pomoci mount, nebo muze taky: cat /etc/mtab, nebo detailneji pomoci: cat /proc/mounts ;)
jestli to dela primo binarka sYsTeMd nebo jeji unit je snad jedno ne? nebo jde o vymluvu kdyz sYsTeMd neco zmrvi "to ja ne, to ten unit"? ;) proste to dela upstream sYsTeMd:
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems#whyareyoutellingmeallthisijustwanttogetridofthetmpfsbackedtmp

[Peter Golis]

Akosi som si nevšimol že by mi SystemD pripájal /tmp v distribúciách Debian alebo Ubuntu, mám to nahlásiť ako bug aby sa to pripájalo?

[k3dAR]

neni potreba(a nejses vtipnej ;), v Debianu uz byl pred casem nahlasen bug ze sYsTeMd 204 automaticky pripojoval tmpfs na /tmp, takze to jiz Debiani mainteneri vyresili a toto upstream chovani zrusili...

[Peter Golis]

Tak vidíš že východzie nastavenia sú vecou distribúcie, a nie upstreamu ako si tvrdil.

[k3dAR]

nikoliv, vychozi nasaveni upstreamu jsou vychozi nasaveni upstreamu, ale jasne trh si to zadal

[Peter Golis]

Áno. Hádam si nemyslíš, že je lepšie aby sa opotrebovávalo SSD zbytočnými zápismi, alebo aby sa zbytočne roztáčali a zastavovali platne mechanického disku? Dnes je už doba, keď sa nevyrábajú ani mobily s menej ako 2G RAM.

[chrono]

Lenže sú ľudia, ktorým nevyhovuje mať napr. zo 4GB RAM dostupných len 2GB.

[Andrej]

Proč přesně by mělo být ze 4 GB přístupných jen 2 GB? Nemáš náhodou nějakou špatnou představu o tom, jak funguje tmpfs?

[chrono]

tmpfs je nejaký zázračný systém, ktorý tie dáta nepotrebuje nikam uložiť?

[Andrej]

Přesně tak. Kdo říká, že tam ty 2 GB budou pořád uložené? 2 GB je limit, nikoliv alokace zabraná nastálo. Když tam bude uložených 100 kB, zabere to 100 kB + nějaký ten overhead.

[Andrej]

A nakonec i kdyby tam trčely celé 2 GB nějakých dočasných dat, neznamená to (obecně), že tím budou pořád zabrané 2 GB RAM — pokud ta mašina má swap (což už sice vyšlo z módy, ale na noteboocích kvůli hibernaci se to stále ještě nastavuje) a na ta dočasná data v tmpfs moc nesahá, časem se tmpfs odswapuje jako kterýkoliv jiný kus RAM a celé 4 GB můžou být k dispozici pro něco, co na RAM sahá častěji.

[lertimir]

Souhlas se swapem. Na pracovní stanici i na noteboocích mám nastaven smysluplný swap a na tmpfs je /dev/shm, /run a /tmp. Obvykle všechny tmpfs mají dohromady cca 20-50 MB, ale když je potřeba tak naberou velikost a při nejhorším se něco odswapuje. A swap pokud je to možné sídlí na SSD, Obavy z opotřebení buněk nejsou při běžném použití na místě. Pracovní stanice se swapem na SSD a hlavně se zapnutým indexováním v KDE má po 4 letech (cca 25000 provozních hodin) použití na 128 GB SSD sumární zápis (ze smart) pod 28TB tedy cca 270 krát přepsané buňky, jednu realokovanou buňku (už rok a půl) a SSD_Life_Left je na 97. Ten odejde dříve na jiné příčiny než přepis.

[k3dAR]

co to sem pletes? uz si zapomel na co reagujes?

[Peter Golis]

Nezabudol. Len Tebe zatiaľ nedocvaklo, že správcovia distribúcie si nastavujú východzie nastavenia podľa svojích predstáv. Ak ich teda majú rozdielne od Upstreamu.

[k3dAR]

vychozi nastaveni upstreamu = vychozi nastaveni upstreamu

[Peter Golis]

Pokiaľ inštaluješ balíčky upstreamu do distribúcií bez použitia balíčkovacieho systému, tak je problém v tom. A nie v upstreame.

[k3dAR]

upstream = upstream, co sem tahas distro? ale chapu kafemlejnek Golis opet zaseklej :)

[Peter Golis]

Nejako nerozumiem čo ti vadí. To čo sa ťa netýka, alebo to že si potrebuješ naprázdno ventilovať problémy. Nemáš niečo duchaplné aj o imigrantoch?

[k3dAR]

me nic nevadi, jen tys motals dohromady veci co spolu nesouvisej, ja vim ze je to tva tradice, Áno...

[GeorgeWH]

Hádam si nemyslíš, že je lepšie aby sa opotrebovávalo SSD zbytočnými zápismi

1. zaujimave, ze poslednu dobu citam, ze ono tie ssd disky vobec nie su take "krehke", ako sa o nich hovori(lo), a ze ich netreba setrit

2. na serveri mam entreprise ssd, ktore su urcene na vysoku zataz

3. kolko sa toho asi tak zapise do /tmp?

aby sa zbytočne roztáčali a zastavovali platne mechanického disku

1. zaujimave, ze ked niekto riesi napr. NAS, tak ho vacsina odhovara od vypinania diskov, pretoze aj tak hovno usetri

2. ked nieco do /tmp zapisuje, tak to logicky muselo byt niecim vyvolane a je velky predpoklad, ze teda ten disk sa uz toci, a zrejme aj nieco loguje atd.

3. ty si v serveroch asi bezne vypinas disky, ze?

Dnes je už doba, keď sa nevyrábajú ani mobily s menej ako 2G RAM.

1. ja mozem osrat aka je dnes doba. to budeme teraz vsetkym plytvat, pretoze je vsetko "lacne"? z chleba si tiez odkrojis jeden krajec a zvysok vyhodis?

2. dnes je este doba, kedy systemy bezne maju "par" mb ram

[Peter Golis]

Prečítal si si pôvodnú otázku aby si pochopil kontext témy? Asi nie.

A ohľadne plytvania, systémy s "par" mb ram majú firmware. Na niečo také už dávno nenainštaluješ OS. Teda, ak si tú mernú jednotku myslel Meaga a nie mili. V tom druhom prípade stráca tvoje vyjadrenie zmysel.

[GeorgeWH]

Vidim, ze debata s tebou fakt nema zmysel.

[chrono]

Je zábavné, keď si niekto v nejakom príspevku nájde nejaký malý problém, ktorý nijako nebráni pochopeniu toho príspevku a všetko ostatné ignoruje.

PS: Mega a nie Meaga. PPS: A zabudol si na to, že B a nie b.

[Peter Golis]

Čo podporuje aj tvoj argument pri používaní kvalitného serverového systému a zároveň obmedzenej ram na niekoľko "mb", nech to "mb" znamená čokoľvek.

[MadCatX]

Takže když si na systému s Upstartem vymyslím skript obsahující

mount tmpfs /tmp -t tmpfs

je to problém Upstartu?

/tmp připojený do tmpfs má daleko menší overhead, i v porovnání s SSD je asi tak 2Ox rychlejší, zabraňuje zbytečným zápisům na médium, případně roztáčení ploten mechanických disků a zajišťuje, že se po restartu adresář /tmp skutečně vyprázdní. Jasně, mít tohle jako výchozí nastavení může chtít fakt jenom šílenec...

[k3dAR]

pokud to vymyslis jako programator Upstartu (a projde to do upstreamu) tak ano, bude to problem Upstartu, nezavisle na tom jestli to bude delat Upstart binarka, nebo Upstart knihovna, nebo Upstart script...
radeji jeste jinak ;) unit tmp.mount je soucasti upstream zdrojaku systemd

[Sten]

Doporučuji si napřed zjistit fakta (ale chápu, že u systemd-haters se to nenosí). Už dlouho před systemd se spoustu podstromů (včetně mnoha tmpfs) mountovala z init skriptů bez ohledu na to, co bylo v /etc/fstab, třeba /run, /dev/shm, /proc, /sys, /sys/kernel/security a mnoho dalších. Ten zlý a ošklivý sysvinit!

[k3dAR]

nepovidej a ja myslel ze systemd je pocatek veku no jasne ze vim co se montovalo bez fstab, ale nebylo to /tmp a o tom byla rec a o tom ze to zacal delat sYsTeMd, ale chapu ze ty jako zastupce systemd_kritics-haters mas potrebu branit sYsTeM(odlu)d ;)

[Sten]

Podle tvého předchozího příspěvku to vypadalo, že jsi o tom neměl ani tušení. Takže sysvinit je taky zlý a ošklivý, když mountuje něco, co není ve fstab, včetně různých tmpfs, že? Ale u systemd to alespoň jde vypnout.

[k3dAR]

mas pravdu, v predchozim mi vypadlo /tmp. talze to mohlo vypadat (pokud se nebrala souvislost s tam uvedenym odkazem ktery resil /tmp nebo souvislost s predchozim predchoziho :) ze pisu obecne o tmpfs v fstab, takze se omlouvam a opravuji:

fstab tmpfs resil

na

fstab tmpfs na /tmp resil

[Sten]

A co jako? Přidal se další adresář, který se automaticky připojuje mimo fstab. No big deal. Takových adresářů se za roky přidávalo mnoho. Zřejmě jsi to nezažil, ale před nějakými 15 lety se nic mimo fstab opravdu nemountovalo (ani /proc, /sys tehdy IIRC ani neexistoval). Ale jestli je to takový problém, tak je to o hodně starší než systemd, které v tom spíš dělá pořádek (konečně to jde rozumně vypínat maskováním jednotek, a ne že se to připojí v bůhvíjakém init skriptu).

Automatické připojování /tmp přebralo systemd z Red Hatu, který to zavedl, protože komerční Unixy to dělají už desítky let. Takže ani nejde o něco, co by si systemd vymyslelo.

[k3dAR]

a co jako? zazil sem Linux pred 21rokama, takovej bordel jako s prichodem sYsTeMd nepamatuju, ale hlavne ze ses spokojenej :)

[Sten]

Bordel v čem? Že podstromy mimo fstab připojuje adresář.mount místo bůhvíjakého init skriptu? A že se to vypne pomocí systemctl mask adresář.mount místo nastavování bůhvíčeho v bůhvíjakém souboru v /etc/default? Nebo je to v /etc/sysconfig? Nebo se to musí předat při bootu? Či je to natvrdo v tom init skriptu a jinak než jeho změnou to nejde udělat? Bordel v tom byl vždycky.

[Prohnutá nudle]

Delal to i debian, dlouho pred systemd, ale mam pocit, ze se to z testingu do stable nikdy nedostalo.

[GeorgeWH]

fstab taky tohle mapování řešit nemá, stav všech mountpointů se má zjišťovat pomocí mount.

dve nesuvisiace veci a z toho prva je blbost - fstab mapuje, co sa kam pripoji. bolo to tak "odjakziva", kym neprisiel systemd(ebilina).

s automatickym mountovanim /tmp do ram som sa naposledy stretol niekde pri mandraku 8, aj to neviem, ci to nebolo nastavene vo fstab a nie v init skriptoch.

[Sten]

bolo to tak "odjakziva", kym neprisiel systemd

s automatickym mountovanim /tmp do ram som sa naposledy stretol niekde pri mandraku 8

Takže tam možná měli systemd deset let předtím, než ho Poettering vůbec začal psát? To jsou věci…

Jinak to bylo „odjakživa“ do přelomu tisíciletí, kdy se začal automaticky mountovat /proc. Potom se přidal /dev, /sys, /dev/shm, /sys/kernel/security a ještě několik dalších adresářů. Všechno roky předtím, než systemd vůbec vzniklo. Ale může za to určitě systemd…

[GeorgeWH]

Takže tam možná měli systemd deset let předtím, než ho Poettering vůbec začal psát? To jsou věci…

to bola skor len taka poznamka bokom. od prechodu na debian (tusim potato alebo woody) som sa s tym nestretol. takze tak. vid aj ten k3dAR-om spominany bug.

/proc, /dev, /sys, /dev/shm, /sys/kernel/security

irelevantne, toto su vyznamovo a funkcne totalne rozdielne fs voci tmpfs (/tmp).

[Sten]

/dev i /dev/shm jsou tmpfs.

[NN]

V dokumentaci Archu se pise, ze je to defaultne polovina RAM, zaroven tam mas priklad, jak si nastavit velikost podle sebe.

[MadCatX]

Adresář /tmp je pomocí tmpfs namapován do RAM. Výchozí maximální velikost je nastavena na polovinu velikosti operační paměti. Toto chování lze na Archu vypnout takto: systemctl mask tmp.mount. Silně však doporučuji toto nastavení neměnit. Pokud je potřeba půjčit yaourtu větší diskový prostor, lze vytvořit soubor ~/.yaourtrc s proměnnou TMPDIR nastavenou na vhodnou cestu.