pine Inbox - RO

Linux-kezdő

Sziasztok!

Van egy szerver, amin a leveleimet ssh + pine párossal szoktam elérni. Eléggé sok spam jön rá, de ez ilyen, nem is érdekel. Tegnap délután óta viszont nem kaptam egyet sem, ami eléggé meglepett. Már napok óta tervezem, hogy kitörlök >1000 levelet, csak eddig nem volt rá időm. Mivel nem jöttek levelek (de hely még minden partíción van!), gondoltam megteszem most, ki is akartam egyet jelölni, de egyből az fogadott, hogy
[Can't delete message. Folder is read-only.]
.

Fogtam, lementettem a filet, majd átneveztem Inbox.ro- ra, és 3 percen belül jött is egy spam az Inbox fájlba.

Az eredeti Inbox 2985 levelet tartalmaz. Hogyan tudom visszaállítani éles használatba, azaz rw- re, hogy tudjak belőle törölni? Persze, kézzel is lehetne, de azzal gondolom nem sokra mennék. Hol tárolja el, hogy egy adott levélfile RO, vagy RW? Nézegettem a forrást. Számomra logikus lenne az első levél fejlécében valahol, ott találtam is egy olyat, hogy STATUS: RO, de ez egy RW mappa leveleiben is megtalálható. ~/.pinerc- ben sem találtam erre utaló jelet.

Köszi a válaszokat, ötleteket.

u. i.: Kb. egy órája próbáltam törölni, ki is jelöltem ~20- 30 levelet, hogy gyorsan legyen valami, de pont akkor váltott IP- t a szolgáltatóm, s azóta a D gomb lenyomására máshogy reagál :- ). Lehet, hogy rosszkor szakadt meg a kapcsolat?, bár ha nem tévedek, az ilyen eseteket kezelnie kellene. Amúgy küldtem rá tesztlevelet is, ami oda nem érkezett meg, viszont vissza sem pattant. Gondolom az ottani levelezőszerver átvette, hogy létezik ilyen fiók, de nem tudta letárolni. Mi történik a tegnap este, és a mostani időpont között küldött levelekkel?

  • 1161 megtekintés

( sas | 2007. 03. 08., cs – 12:08 )

Szerintem válts Alpine-ra, ha az Etpan, Mutt vagy más nem tetszik.

( tr1719 | 2007. 03. 08., cs – 12:59 )

Közben találtam a /tmp/- ben egy .800009.1dade6 nevű filet, ami látszólag egy PID- et tartalmazott. Miután kitöröltem a filet, pine hagyta, hogy D- nek jelöljem a leveleimet, de amikor ki akartam lépni, eléggé úgy néz ki, hogy befagyott. Solarison hogyan lehet megnézni, hogy mely processzek eszik a legtöbb procit? (top d 1, ps axu nem igazán úgy működik, mint Linuxon).

Hi!

Köszi, közben freenode- n megkaptam ugyanezt az infót, de itt nincsen fent, de gyanítom, hogy <10 rendszerrel van dolgom. A fura az volt az egészben, hogy hazahoztam az Inbox filet, itthon kitöröltem ~500 levelet, visszamásoltam a solarisra, és ott - miután töröltem a /tmp/- ben lévő filet - megint elszállt, amikor törlés után próbáltam kilépni, vagyis befagyott. Próbáltam, hogy a ~/.pinerc- t átneveztem, de akkor is ugyanezt a hibát kaptam. Hol vannak még a pine- hoz kapcsolódó beállító filek? A solarison lévő pine verziószáma 4.00, az itthonié 4.64.

Húha, a 4.00-ás jó régi...
Az uname -a mit mond?
Asszem a sun.com-on van fent Companion cd/dvd a régebbi Solarisokhoz is (8+9-hez biztos), és onnan egyesével is le lehet rántani a csomagokat, top is van közöttük.
Az még segíthet.
A pine-nyavajára _most_ nem sok ötletem van, de esetefele megnézem.
A /var (esetleg /var/mail) külön partíció? Mit lehet róla tudni? (Az fs esetleg full, ilyesmi miatt kérdezem; én is pine-t (is) nyúzok sok éve, ilyen bajsággal még nem találkoztam, de mindig tanul az ember újat... :))

(Ne siess a válasszal, 7 körül tudok visszakukkantani, addig órám lesz mindjárt :(
a

Szia!

Fordítottam egy 4.64- es pinet. Igaz, nem szántam rá túl sok időt, de az be sem hozta a leveleket :- ). 

uname -a
SunOS tigris 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-2

Na most az adott rendszerhez semmilyen rendszerszintű jogom nincsen. A /var csatolt partíció, és még van rajta hely. Itt viszonylag gyakran előfordult, hogy elfogyott a hely, de ez most az az eset, amikor még van :- ). Sejtettem, hogy gond lesz, mert mióta a leveleim száma elérte a 2000- et nagyjából, egyre lassabban indult. Volt, hogy 15- 20s. Most is elindul ugyan, ha azt a most ~2400 levelet tartalmazó filet ( 

 pine -f filename

) próbálom meg betölteni, de ro- nak látja, ami számomra nem túl szerencsés :- ).

Köszi.

Largefile probléma? A 7-esben még a 64 bit eléggé zehernyésen működik. Mintha...
Mondjuk nem hinném, hogy 2GB az Inboxod :)

Quota? (Sőt: soft/hard quota?)

Még egy dolog beugrott: nem lehet, hogy maradt egy pine process valahun? Próbálj egy "pkill pine" parancsot kiadni, ez elvileg minden "pine" stringet tartalmazó processzt fejbevág.

Még egy tipp:
http://www.fas.harvard.edu/computing/kb/kb0014.html

Jövök még!

Hi!

50MB az Inbox, szóval a 2GB- s limit még messze van :- ).

Nincs quota az adott rendszeren, így ez is kilőve. A bent ragadt pine processz, vagy valami hasonló lehetséges, láttam is 2 defunct processzt, de azokram eresztettem kill -9- et. Amiért amúgy ezt nem tartom valószínűnek, az az, hogy az új Inbox filet simán tudom írni, bejövő levelek is rendre megérkeznek, viszont a hiba csak a nagy 50MB- s Inbox.ro fileval áll fenn. Hm, legnagyobb meglepetésemre még most is ott van a 2 defunct process, és kill -9 után is ott marad.

Uh, most rájuk eresztettem egy pkill- t, és most már 3 van. Ezeket hogy lehet kilőni? Hogy tudom solarison megnézni, hogy ki a szülőjük? ps -a- ból nem látszik, pstree meg nincs a rendszerben. pkill pine- t is kipróbáltam, de ettől még ugyanúgy ott van a 2 defunct processem. Hogy lehet tőlük megszabadulni? :- ).

Köszi.

( aspirin v | 2007. 03. 08., cs – 22:54 )


Mi történik a tegnap este, és a mostani időpont között küldött levelekkel?

Elvan vele valamelyik relay host :)
Ha nagyon nem boldogul, egyszer majd kapsz egy levelet, hogy nem tudja kézbesíteni, de még próbálkozik, aztán (esetleg napok múlva) még egyet, aztán ~7-8 nap után jön, hogy "sorry I have given up..."
(vagy nem; lehet, hogy valahol /dev/null-ban kötött ki, de ez nagyon nem valószínű)

Pine-ügyben mi a helyzet?

Van system-wide pine config file, de hogy hol az a rencergazditól függ. pine.conf -ot keress (elvileg). Én ebben nem találtam inbox ro/rw beállítási lehetőséget, de hátha.

Esetleg az Inbox file kutyulódhatott össze, (az előzőekben már küldtem linket)

Még valami: nem lehet, hogy valamilyen UTF/akármi karakter vágta haza az Inboxot? Nemtom otthon milyen renceren használod a Pine-t, meg a Solarison mi a helyzet locale-ügyileg, de az ördög sosem alszik.

Egyelőre ennyi, lemerült a duracell...

Szia!

Közben megoldódott, de leírom nagyvonalakban, hogy mi volt (szerintem) a probléma.

Hasnzáltam ugye ezt 2985 levelet tartalmazó filet. Éppen léptem ki, ez szokott tartani 8- 10 másodpercig, de közben szakadt a kapcsolatom (lejárt a 24 óra), és valamiért nem fejeződött be a pine processz kilépési része, hanem defunct lett. Ezzel ugye ott maradt a lockfile a /tmp/- ben. Na most az egy érdekesebb kérdés, hogy annak a törlése után miért nem hagyta szintén írni azt a nagy filet. Um, nevezzük el őket. Legyen Inbox.ro az, ami a sok levelet tartalmazza, és Inbox.ok, ami az új. <100 levelet tartalmazó fájl.

Az volt az érdekes, hogy az összes tmp- beli nevem alatt szereplő lock file törlése utána is fennállt az, hogy az Inbox.ok- on minden műveletet hiba nélkül végrehajthattam, viszont Inbox.ro- n kilépésnél defunctolt. Fentebb említetted a ps -ef parancsot. Le kellett volna mentenem a kimenetét, mert olyat még nem láttam, de elképesztő volt. Legalább 20 sor (processz) volt, aminek a paraméterei között szerepelt egy emailcím, hogy éppen azt a levelet próbálja meg kézbesíteni nekem! Ilyenből még egyet sem sikerült elkapnom kis levélforgalmú rendszeren, nem hogy 20- at. Nagyjából, ha minden igaz, valahol volt egy beragadt lock (mint mondjuk szálaknál egy mutex változó, csak itt nem szálak, hanem folyamatokról van szó), és mindenki erre vált (talán ezt hívják konvoj hatásnak). Az, hogy a pine hibája lett volna, kizárható úgy, hogy mutt is hasonlót produlkált. Persze a kiváltó ok nyílván pine hiba volt (vagy valami, ez most mindegy), de azt nagyon helyesen tette, hogy nem írta meg a filet a beragadt folyamat miatt. Jó ideje használok pine- t, ~97 óta, de ez az első eset, ami azt mutatja, hogy lehet valami abban, hogy egy fileban csak egy levelet tároljunk (mbox <-> Mailbox).

Remélem nem írtam túl sok hülyeséget az összefoglalómban. Köszi még1X a segítséget.

Igen, vagy MTA, vagy MUA. Ma is produkált egyszer egy ro dolgot a kedves, de ezek szerint újabban nem szereti, ha egyszerre több pinet futtatok, viszont már megint nem kapok meg a leveleimet. Ez egy nem túl nagy terheltségű szerver, szerintem átlagban sincsen 10- nél több levél percenként, de inkább még kevesebb, és amikor küldök egy levelet, egyből átveszi kézbesítésre. Most nézegettem 

 ps -ef

- et, és találtam ~50 ilyen sort: 

 /usr/lib/sendmail -q15m

és másik 50 ilyet: 

 /usr/lib/sendmail -bd -OPrivacyOptions=noetrn -ODeliveryMode=queueonly -OQueueD

Ezekhez nagyon nem értek. Tulajdonképpen mik ezek? Tippem szerint ezeknek kellene kézbesíteni 1- 1 levelet, de már jó ideje ott vannak, van amelyik 2 óra 40 perce. Lehetséges, hogy valami nagyon nem stimmel a rendszerben, és megint feltartja valami a sort, csak most nem user, hanem rendszer szinten? Ha küldök onnan kifele egy levelet, az azonnal megérkezik, még gyorsan kipróbálom, ha onnan oda. Utóbbi is pillanatok alatt megérkezik, csak az nem, ami kívülről jön... .

Halihó!

Hopp, most láttam, hogy volt folytatás... :)

A 

/usr/lib/sendmail -q15m

a sendmail queue-val foglalkozó része (-q), ez csekkolja 15 percenként (15m) a kimenő queue-t, meg a relay-ről rántja le a leveleket (nem biztos, hogy a bejövőt is, de úgy dereng)

A másik sor érdekesebb, mert nekem 2 gépen is a következő sendmail-ek futnak: 

   
   root 10198     1   0   Feb 13 ?           1:07 /usr/lib/sendmail -bd -q15m
   smmsp 10199    1   0   Feb 13 ?           0:03 /usr/lib/sendmail -Ac -q15m

Aszongya:
http://en.wikipedia.org/wiki/ETRN
Ha a queueonly-t kiveszed, akkor azonnal elküldi a levelet, nem csak 15 percenként "néz rájuk".

a -bd meg símán az, hogy daemon-ként fusson a háttérben: 


−bx Set operation mode to x. Operation modes are:
              m      Deliver mail (default)
              s      Speak SMTP on input side
              a†    ‘‘Arpanet’’ mode (get envelope sender information from header)
              d      Run as a daemon in background
              D      Run as a daemon in foreground
              t      Run in test mode
              v      Just verify addresses, don’t collect or deliver
              i      Initialize the alias database
              p      Print the mail queue
              P      Print overview over the mail queue (requires shared memory)
              h      Print the persistent host status database
              H      Purge expired entries from the persistent host status database

Az OQueueD szerintem kéne, hogy folytatódjon, ez lenne a queue directory. (Legalábbis ez a legközelebbi általam ismert sendmail kapcsoló :)), ezzel nem kell foglalkozni.

Tehát:
_elvileg_ kábé 15 percenként kéne, hogy jöjjön-menjen a levél. Hogy miért nem ezt teszi, nemtom, lehet, hogy a sendmail.cf, vagy delivery.cf, vagy akárni.cf-ben más áll... bááár ezt felül kellene bírálnia a parancsornak.
Az is lehet, hogy a $relayhost-otok leterhelt, és van egy-két levél, amit valamiért nem vesz át, így a sendmail meg próbálkozgat tovább.