neo-21670:

Apró ötlet: elegem volt a script/server típusú szerverindítgatásból, ami ráadásul “csúnya” megoldás, mert nem magától fut, külön minden projekthez egy StartupItemet gyártani (OSX) nem túl esztétikus megoldás. Keresgélés után végül a Passenger mellett döntöttem, egyszerű telepíteni, gyorsan összetracskolható az Apache-csal. Ugyanakkor ha Rails-es projekt fejlesztése közben az initializer-ekkel kell dolgozni, macerássá válik: a Passenger a szerver indításakor felnyalja az environment.rb-t és - bár más fájlok változását észreveszi - pont az initializereket nem lehet módosítani emiatt. (Illetve nyilván lehet, csak újra kell indítani hozzá a szervert, így meg oda az elegáns, állandó újraindítgatástól mentes munka.)

Nem teljesen kézenfekvő ugyan, és a problémával is kevesen foglalkoznak, de a dokumentációból tkp. összerakható a megoldás.

<VirtualHost *>
    ServerName projekt1
    DocumentRoot /sites/projekt1
    RailsEnv development
    RailsSpawnMethod conservative
    PassengerMaxRequests 1
</VirtualHost>

RailsEnv nem létszükséglet, de mindenhol javasolják, hogy konkrétan állítsuk be development módra - még nem tudom, hogy ez befolyásolja-e a Passenger viselkedését. PassengerMaxRequests 1 - ettől a Passenger az adott app instance-ét kiüti a kiszolgált request után. Nem a legelegánsabb megoldás, de automatikus újraindítást jelent, ergo initializeres tesztelős-tracskolós időkben enyhíti a lelki bajokat. RailsSpawnMethod conservative - amíg smart-lv2 vagy smart módban volt a szerver, a becache-elt framework kód (aminek ezek szerint része az initializers is) nem volt hajlandó “kiürülni”. Conservative módban nincs gyorstárazás, restartkor újratöltődik minden, amit szeretnénk, ellenben minden lassabb lesz: a reload miatt oldalbetöltődésenként mondjuk 3-4 sec is eltelhet.