clamav túlterhelés indításkor

Fórumok

Sziasztok!

Adott egy XEN virtuális gép Debian 4.0 Etch OS-el.

Ezen van többek között egy clamav is, ami indításkor maxra terheli a procit, nem hozza létre a /var/run/clamav/clamd.ctl és a /var/run/clamav/clamd.pid fájlokat se, tehát az amavisd-new se tud vele addig dolgozni.

Kb 3-5 perc múlva létrejönnek a fájlok, leesik a terhelés, és minden működik, ahogy illik.

Mi lehet a baja?

2, Nem tartozik szorosan ide, de hogyan lehet megvalósítani, hogy a stable debianba mindig a legújabb clamav legyen, úgy, hogy az apt-get upgrade ne frissítsen mást?

Előre is köszi!

Hozzászólások

2, Nem tartozik szorosan ide, de hogyan lehet megvalósítani, hogy a stable debianba mindig a legújabb clamav legyen, úgy, hogy az apt-get upgrade ne frissítsen mást?

Azokat a csomagokat, amiket nem akarsz frissíteni, azokat HOLD állapotra kell tenni.

Ha csak a clamavot akarod frissíteni, akkor használd csak a volatile.debian.org repót, és a többit meg ne.

Az elsődre nincs ötletem, próbáld meg a volatile-n levő clamav és clamav-data csomagokat...

----------

Nem a zsömle kicsi, a pofátok nagy...

Azokat a csomagokat, amiket nem akarsz frissíteni, azokat HOLD állapotra kell tenni.

ez nem elegáns, mert akkor semmit se fog frissíteni a biztonsági frissítések közül se, ráadásul ha új csomagot teszek fel, akkor nem a stable repóbol szedné le, mert van újabb mondjuk az unstable-ben :-(

Ha csak a clamavot akarod frissíteni, akkor használd csak a volatile.debian.org repót, és a többit meg ne.

ezt máris megnézem, köszi a tippet!

-------------szerk--------------

ez megoldotta mindkét bajomat, köszi érte!

--
by Mikul@s

a clamav a dom0-án vagy a domU-n nem futna ?

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.22

és addig a 3-5 percig mit csinál ? nagy forgalmú levelező szerver? mert attól hogy Xen alatt fut nem kéne hogy gondot jelentsen. Nekem xen alatt jópár gép fut
és egyikkel sincsen semmi gond. mondjuk nagyforgalmú mailszerver nincsen közte.

az is kérdés hogy akkor van ez mikor a másik 4-5 stb domU is elindul, mert akkor lehet hogy kevés az I/O, vagy akkor is csinálja ha csak saját maga fut?

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.22

amíg "teker", addig nem üzemel, az amavis nem tud hozzá csatlakozni, ergó a postfix dobálja a leveleket a deferredbe

de meg is oldódott mindkét problémám, a volatile repó frissítette a clamavomat -ahogy szerettem volna- és már rendesen működik a clamav is!

köszi mindkettőtöknek a gyors és hatékony segítséget!

--
by Mikul@s

xen-hez nincs koze. a virus db-t tolti olyan sokaig. ez meg nem is lenne gond, de ha utana elindul az amavis is, es mar ellenorizne a leveleket, primarykent clamd-t nem eri eli, secondarykent probalkozik sima clamscan-nel, ami meg szinten elkezdi toltogetni a virus db-t, processzenkent...

sejtettem, hogy nem XEN dolog lesz, de logikázzunk: ha a fent említett 2 fájlt a virusdb betöltése előtt kellene létrehoznia, akkor üzemszerűen működ(het)ne, ebben az esetben bugos volt ez a clamav csomagolás, de akkor másnak ez nem tűnt volna fel?

mindenesetre, most már zsír

--
by Mikul@s

virusdb nelkul nem tud mukodni egy viruskereso ;)
meg ez nem hinnem, hogy bugnak minosul, van egy "kis" ido, amig inicializal.
bar tenyleg hamarabb letrehozhatna a unix socketet, max annyi, hogy akkor varakozni kell a processznek, aki csatlakozik ra, de ott meg elofordulhat timeout, ha percekig eltart.

a repó bővítés óta ezt problémázza:

"W: GPG error: http://volatile.debian.org etch/volatile Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EC61E0B0BBE55AB3
W: You may want to run apt-get update to correct these problems"

letöltöttem innen (http://volatile.debian.org) az etch-volatile.asc-t be is másoltam az /etc/apt alá, de nem változott semmi...

hová és mit?

--
by Mikul@s