Újabb egy hét csúszás a Fedora 18 kiadási ütemtervében

 ( trey | 2012. szeptember 2., vasárnap - 13:35 )

Jaroslav Reznik nemrég bejelentette, hogy a korábban jelzett egy hetes csúsztatás mellé egy újabb hetet be kell beiktatni a Fedora 18 kiadási ütemtervébe. Az augusztus 30-án tartott Go/No-Go meetingen döntöttek úgy a fejlesztők, hogy újabb egy héttel eltolják a Fedora 18 Alpha kiadását. Az Alpha újabb csúsztatása egyben azt is jelenti, hogy a Fedora 18 kiadási ütemtervének főbb mérföldkövei - beleértve a végleges kiadás tervezett dátumát is - szintén újabb egy héttel eltolódnak.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Mondjuk nem bánom. Hajmeresztő a feature lista, valahogy az az érzésem, ennyi változtatás után esélytelen, hogy ez még működjön is.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A sok közül ez örvendetes: "Mount a tmpfs on /tmp by default."

Izgalmasan hangzik:
- Virt Live Snapshots
- Secure Containers (virt-sandbox-server)

a tmpfs-mountolás nem aratott osztatlan elismerést:)

http://lists.fedoraproject.org/pipermail/devel/2012-August/171022.html

A /tmp -ben ez meg istenes, a /var/run azonban katasztrofalis tud lenni. Most gyurogetek egy 12.1-es opensuse-t, ahol szinten tombol a tmpfs orulet, es egyszeruen vannak olyan programok, amik nem hajlandok a socketjeiknek mappat gyartani. Ha belehekkelem az init scriptbe, akkor meg ki tudja, mikor fog frissulni a cucc es elmaszni megint az egesz. Gyasz. Mondjuk ez az egesz systemd szarul van megcsinalva.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

man tmpfiles.d :)

Kosz. Ettol meg hulyeseg.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

De miért? Permanens dolgokhoz ott a /var. Ma meg már SSD lesz a jellemző. Főleg desktop-on. Irkáljanak csak szépen a RAM-ba.

Egy socket nem permanens dolog, egy socket mappaja viszont az.

A problema a kovetkezo: php-fpm -et konfigolok, es az egyes pool-ok UNIX socketen figyelnek, igy kapcsolodnak az elotetkent szolgalo webszerverhez (jelenleg nginx). Namarmost, mivel az nem jo, ha csak a /var/run -ba vannak beszorva a socketek, igy en a /var/run/php-fpm mappaba rakom oket. Ez korabban teljesen jol is mukodott, hiszen a mappa a disken volt, sose tunt el. Viszont a tmpfs sajnos nem orzi meg az ilyen mappakat.

Altalanossagban veve meg azert nem szeretem a tmpfs-t, mert nem kerul diskre. Neha hasznos volt, ha tudtam, milyen szervizek futottak pontosan, amikor a gep megdoglott.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A szolgáltatás hozza létre a mappáját. Ez a legtisztább megoldás IMHO.

Hat, jelenleg beleganyoltam az init scriptbe, hogy ez tenyleg igy legyen. Viszont a PHP-FPM-nek ez nem a sajat mappaja, igazabol a socketeket kb. akarhova tehetnem. Viszont a runtime valtozo adatoknak (PID file, socket) a /var/run van fenntartva, tehat ugy dontottem, hogy szabvanykoveto leszek, es en is ide pakolok. Mivel nem szeretem a rumlit, ezert csinaltam egy dedikalt mappat erre. Ez a systemd elotti idokig mukodott is.

Szoval ez azert annyira nem trivialis kerdes.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal