Moin!
Folgendes erscheint mir ab und zu im mutt (Threadzeichen von Hand repariert):
5 N L 28.Apr Douglas Gilbert 65 [PATCH] ide-scsi 2.5.10-dj1 compilation fail 6 N L 27.Apr Martin Dalecki 32 |-> {Cc linux-kernel@vger.kernel.org} 7 N L 27.Apr Martin Dalecki 32 ||=> {Cc linux-kernel@vger.kernel.org} 8 N L 28.Apr Douglas Gilbert 65 |=> {To linux-kernel@vger.kernel.org}
D.h. #6 und #7 sowie #5 und #8 sind identisch (weshalb mutt wohl auch das '=' malt). Mails werden per fetchmail abgeholt und per exim lokal zugestellt. Das passiert auch nicht immer und auch nicht mit allen Mails. Hat das schon mal jemand erlebt? Hab leider nix dazu finden können. Meine Vermutung: entweder holt fetchmail diese Mails doppelt ab, oder exim verschluckt sich. (das sind die einzigen Faktoren die sich in letzter Zeit geändert haben)
Gruß, Eric
Once upon a time, I heard Eric Schaefer say:
Mails werden per fetchmail abgeholt und per exim lokal zugestellt.
Wenn fetchmail - aus was für einem Grund auch immer - irgendwo mittendrin abbricht, werden die mails auf dem Server nicht gelöscht und beim nächsten Mal wieder geholt... bis es einmal richtig klappt, dann werden sie auch auf dem Server gelöscht.
... [duck] zumindest ist das bei POP3 über fetchmail so.
Ansonsten kann es doch nur noch eine kaputte Filterregel sein (procmail, exim)...?
hej så länge.
On Sun, Apr 28, 2002 at 11:27:51AM +0200, Stefan Berthold wrote:
Once upon a time, I heard Eric Schaefer say:
Mails werden per fetchmail abgeholt und per exim lokal zugestellt.
Wenn fetchmail - aus was für einem Grund auch immer - irgendwo mittendrin abbricht, werden die mails auf dem Server nicht gelöscht und beim nächsten Mal wieder geholt... bis es einmal richtig klappt, dann werden sie auch auf dem Server gelöscht.
Kommt bei mir auch vor (ca. 1mal im Monat)
... [duck] zumindest ist das bei POP3 über fetchmail so.
Ich tippe auch auf fetchmail.
Zur Diagnose eventuell --syslog oder --verbose ausprobieren und schauen, ob fetchmail alles richtig abholt.
Ansonsten kann es doch nur noch eine kaputte Filterregel sein (procmail, exim)...?
Alles ist möglich...
Bert
On Sun, Apr 28, 2002 at 11:27:51AM +0200, Stefan Berthold wrote:
Once upon a time, I heard Eric Schaefer say:
Mails werden per fetchmail abgeholt und per exim lokal zugestellt.
Wenn fetchmail - aus was für einem Grund auch immer - irgendwo mittendrin abbricht, werden die mails auf dem Server nicht gelöscht und beim nächsten Mal wieder geholt... bis es einmal richtig klappt, dann werden sie auch auf dem Server gelöscht.
... [duck] zumindest ist das bei POP3 über fetchmail so.
Das kann es nicht sein, fetchmail läuft in einem Rutsch durch.
Ansonsten kann es doch nur noch eine kaputte Filterregel sein (procmail, exim)...?
Alle procmail-Regeln sehen so aus:
---snip--- :0: * ^TOlug-dd@schlittermann.de /home/eric/Mail/lug-dd ---snip---
Deine Mail bekam ich doppelt, aber z.B. alle aus dem "Linux 8.0" Thread nicht. Sehr komisch... Im procmail.log stehen auch zwei einzelne Mails drin.
exim.conf: ---snip--- procmail_pipe: driver = pipe command = "/usr/bin/procmail -d ${local_part}" return_path_add delivery_date_add envelope_to_add check_string = "From " escape_string = ">From " user = $local_part [...] procmail: driver = localuser transport = procmail_pipe require_files = ${local_part}:+${home}:+${home}/.procmailrc:+/usr/bin/procmail no_verify ---snip---
Hmm, ich gerade, daß es doch am fetchmail liegen könnte: ---snip--- Apr 28 13:15:29 zeus fetchmail[229]: 10 messages for pt6576173-0815 at pop.kundenserver.de (42281 octets). Apr 28 13:15:31 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:1 of 10 (2133 octets) Apr 28 13:15:32 zeus fetchmail[229]: flushed Apr 28 13:15:32 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:2 of 10 (3109 octets) Apr 28 13:15:32 zeus fetchmail[229]: flushed Apr 28 13:15:35 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:3 of 10 (2887 octets) Apr 28 13:15:36 zeus fetchmail[229]: flushed Apr 28 13:15:36 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:4 of 10 (1895 octets) Apr 28 13:15:36 zeus fetchmail[1200]: 10 messages for pt6576173-0815 at pop.kundenserver.de (42281 octets). Apr 28 13:15:37 zeus fetchmail[229]: flushed Apr 28 13:15:37 zeus fetchmail[1200]: reading message pt6576173-0815@pop.kundenserver.de:1 of 10 (2133 octets) Apr 28 13:15:37 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:5 of 10 (8783 octets) Apr 28 13:15:37 zeus fetchmail[1200]: flushed Apr 28 13:15:40 zeus fetchmail[1200]: reading message pt6576173-0815@pop.kundenserver.de:2 of 10 (3109 octets) Apr 28 13:15:40 zeus fetchmail[229]: flushed Apr 28 13:15:41 zeus fetchmail[1200]: flushed Apr 28 13:15:41 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:6 of 10 (4538 octets) Apr 28 13:15:41 zeus fetchmail[229]: flushed Apr 28 13:15:41 zeus fetchmail[1200]: reading message pt6576173-0815@pop.kundenserver.de:3 of 10 (2887 octets) Apr 28 13:15:42 zeus fetchmail[1200]: flushed Apr 28 13:15:42 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:7 of 10 (2838 octets) Apr 28 13:15:43 zeus fetchmail[229]: flushed Apr 28 13:15:43 zeus fetchmail[1200]: reading message pt6576173-0815@pop.kundenserver.de:4 of 10 (1895 octets) Apr 28 13:15:44 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:8 of 10 (7900 octets) Apr 28 13:15:45 zeus fetchmail[1200]: flushed Apr 28 13:15:47 zeus fetchmail[229]: flushed Apr 28 13:15:47 zeus fetchmail[1200]: reading message pt6576173-0815@pop.kundenserver.de:5 of 10 (8783 octets) Apr 28 13:15:47 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:9 of 10 (4919 octets) Apr 28 13:15:48 zeus fetchmail[229]: flushed Apr 28 13:15:49 zeus fetchmail[1200]: flushed Apr 28 13:15:49 zeus fetchmail[229]: reading message pt6576173-0815@pop.kundenserver.de:10 of 10 (3279 octets) Apr 28 13:15:50 zeus fetchmail[229]: flushed Apr 28 13:15:50 zeus fetchmail[1200]: reading message pt6576173-0815@pop.kundenserver.de:6 of 10 (4538 octets) Apr 28 13:15:51 zeus fetchmail[1200]: flushed Apr 28 13:15:53 zeus fetchmail[1200]: client/server protocol error while fetching from pop.puretec.de Apr 28 13:15:53 zeus fetchmail[1200]: Query status=4 (PROTOCOL) ---snip---
Mehrere Mail werden scheinbar doppelt abgeholt und dann zum Schluß noch irgendein Fehler.
fetchmailrc: ---snip--- set no bouncemail set syslog poll pop.puretec.de protocol pop3 username "xyz" password "abc" is eric here ---snip---
OK, Problem erkannt. Die Zahl im syslog in der [] ist wohl die pid? Hmm, das läuft hier als Daemon und ich starte es außerdem bei Bedarf von Hand. Das scheint sich eben ab und zu zu überschneiden. Böse, böse. Da muß ich wohl nachsitzen...
Danke erstmal.
Gruß, Eric
On Sun, Apr 28, 2002 at 01:43:24PM +0200, Eric Schaefer wrote: [fetchmail]
OK, Problem erkannt. Die Zahl im syslog in der [] ist wohl die pid? Hmm, das läuft hier als Daemon und ich starte es außerdem bei Bedarf von Hand. Das scheint sich eben ab und zu zu überschneiden. Böse, böse. Da muß ich wohl nachsitzen...
Gegeben sei ein Prozess mit der uid='fetchmail' und gid='nogroup'. Wie kann ein beliebiger Nutzer 'abc' diesem Prozess ein SIGUSR1 schicken?
Gruß, Eric
On Sun, Apr 28, 2002 at 01:56:07PM +0200, Eric Schaefer wrote:
On Sun, Apr 28, 2002 at 01:43:24PM +0200, Eric Schaefer wrote: [fetchmail]
OK, Problem erkannt. Die Zahl im syslog in der [] ist wohl die pid? Hmm, das läuft hier als Daemon und ich starte es außerdem bei Bedarf von Hand. Das scheint sich eben ab und zu zu überschneiden. Böse, böse. Da muß ich wohl nachsitzen...
Gegeben sei ein Prozess mit der uid='fetchmail' und gid='nogroup'. Wie kann ein beliebiger Nutzer 'abc' diesem Prozess ein SIGUSR1 schicken?
Weiß ich auch nicht.
Ich habe mir ein Script gebastelt, welches fetchmail, exim, leafnode und sitecopy startet. Dieses Script wird regelmäßig vom crond aufgerufen. Wahlweise kann ich es auch per Hand (mittels sudo) oder über meinen lokalen Webserver starten.
Script siehe Anhang.
Bert
On Sun, Apr 28, 2002 at 02:19:51PM +0200, Bert Lange wrote:
Ich habe mir ein Script gebastelt, welches fetchmail, exim, leafnode und sitecopy startet.
.muttrc: ---schnipp--- macro index "z" "!~/getmail\n" ---schnapp---
~/getmail: ---schnupp--- #!/bin/sh echo -n "flushing mail..." /usr/sbin/exim -qf echo "done." echo -n "fetching mail..." fetchmail echo "done." echo -n "delivering local mail..." /usr/sbin/exim -qfl echo "done." ---schnepp---
Dieses Script wird regelmäßig vom crond aufgerufen. Wahlweise kann ich es auch per Hand (mittels sudo) oder über meinen lokalen Webserver
^^^^
starten.
Da liegt der Elefant im Kümmel. *vordenkopfschlag* Naja, es ist Sonntag.
Weil wir (bzw. ich) gerade dabei sind: Irgendwie kann ich es meinem mutt nicht abgewöhnen, Umlaute oktal darzustellen. In den Mails stehen prima 8bit/Latin-1 Umlaute drin, alle anderen Programme kommen damit klar, nur mutt nicht. Die Konfiguration ist die gleiche, wie die aufm Unirechner, wo alles prima ging. Fällt daz jemandem was ein?
Gruß, Eric
On 28.04.02 Eric Schäfer (eric@gixgax.de) wrote:
On Sun, Apr 28, 2002 at 02:19:51PM +0200, Bert Lange wrote:
Moin,
Ich habe mir ein Script gebastelt, welches fetchmail, exim, leafnode und sitecopy startet.
drachi:[hille] >more /etc/ppp/ip-up.d/fetchmail_local #!/bin/bash -- for HOMEDIR in /home/*; do if [ -e ${HOMEDIR}/.fetchmailrc ]; then su - ${HOMEDIR#/home/} -c "/usr/bin/fetchmail -d 240" fi done
Die anderen Dienste haben ähnliche Skript, die gemäß run-parts abgearbeitet werden. In /etc/ppp/ip-down.d/fetchmail wird dann mit fetchmail --quit alles wieder beendet.
Weil wir (bzw. ich) gerade dabei sind: Irgendwie kann ich es meinem mutt nicht abgewöhnen, Umlaute oktal darzustellen. In den Mails stehen prima 8bit/Latin-1 Umlaute drin, alle anderen Programme kommen damit klar, nur mutt nicht. Die Konfiguration ist die gleiche, wie die aufm Unirechner, wo alles prima ging. Fällt daz jemandem was ein?
Du hast noch eine Debian-testing mit dem Bug im locales-Paket, so daß Du beim Installieren desselbigen nicht gefragt wurdest, welche lokale settings Du installieren möchtest und welche default sein sollen? -> dpkg-reconfigure locales
H.
On Mon, Apr 29, 2002 at 06:05:14PM +0200, Hilmar Preusse wrote:
Du hast noch eine Debian-testing mit dem Bug im locales-Paket, so daß Du beim Installieren desselbigen nicht gefragt wurdest, welche lokale settings Du installieren möchtest und welche default sein sollen? -> dpkg-reconfigure locales
Ah ja, das hats wohl beim "apt-get upgrade" irgendwie zerschossen. Da war nur de_DE@euro ausgewählt, welches hier irgendwie nicht funktioniert. en_US tut es aber... Warum aber nur mutt damit Probleme hatte, versteh ich trotzdem nicht.
Noch 1h 22min bis Woody/stable? Ich wette ein (1) Pils dagegen...
Danke, Eric
Am Dienstag, dem 30. April 2002 um 22:38:17, schrieb Eric Schaefer:
Noch 1h 22min bis Woody/stable? Ich wette ein (1) Pils dagegen...
Nix zu wetten, es wird kein Woody zum 1. Mai geben.
Torsten
On 30.04.02 Eric Schäfer (eric@gixgax.de) wrote:
Moin,
Noch 1h 22min bis Woody/stable? Ich wette ein (1) Pils dagegen...
Date: Tue, 30 Apr 2002 19:04:06 +1000 To: debian-devel-announce@lists.debian.org Subject: [2002-04-30] Release Status Update Message-ID: 20020430090406.GA32694@azure.humbug.org.au
:-(
H.
Eric Schaefer wrote:
On Sun, Apr 28, 2002 at 01:43:24PM +0200, Eric Schaefer wrote: [fetchmail]
OK, Problem erkannt. Die Zahl im syslog in der [] ist wohl die pid? Hmm, das läuft hier als Daemon und ich starte es außerdem bei Bedarf von Hand. Das scheint sich eben ab und zu zu überschneiden. Böse, böse. Da muß ich wohl nachsitzen...
Gegeben sei ein Prozess mit der uid='fetchmail' und gid='nogroup'. Wie kann ein beliebiger Nutzer 'abc' diesem Prozess ein SIGUSR1 schicken?
kill -s SIGUSR1 `ps -o "pid user group"\ | egrep '^[0-9]+ +fetchmail +nogroup *$' | cut -d ' ' -f 1`
... vielleicht wäre noch ein "-C fetchmail" beim ps angebracht, falls das Kommando für den Prozeß so heißt ...
Gruß, Eric
Jens
Hi,
* Eric Schaefer [04/28/02 13:43:24 CEST] wrote:
[...]
Apr 28 13:15:29 zeus fetchmail[229]: 10 messages for pt6576173-0815 at pop.kundenserver.de (42281 octets).
^^^^^^^^
Apr 28 13:15:36 zeus fetchmail[1200]: 10 messages for pt6576173-0815 at pop.kundenserver.de (42281 octets).
^^^^^^^^ [...]
OK, Problem erkannt. Die Zahl im syslog in der [] ist wohl die pid?
Ja.
Hmm, das läuft hier als Daemon und ich starte es außerdem bei Bedarf von Hand. Das scheint sich eben ab und zu zu überschneiden. Böse, böse. Da muß ich wohl nachsitzen...
...und dein Fetchmail updaten/richtig konfigurieren. Meines erstellt ein pid-File, wenn es startet. D.h., wenn ich es manuell starte und just in diesem Moment der Cronjob anspringt, sagt er mir (sinngemaess): 'another foreground fetchmail running at pid ...'
Dieser Mechanismus funktioniert allerdings nur, wenn fetchmail jeweils unter der gleichen UID laeuft. Deshalb habe ich keinen Daemon-Mode sondern besser einen Cronjob. In der manpage steht glaube ich auch, dass es nur einen Run pro User gleichzeitig geben darf.
Cheers, Rocco.
Hi,
* Eric Schaefer [04/28/02 09:56:09 CEST] wrote:
Folgendes erscheint mir ab und zu im mutt (Threadzeichen von Hand repariert):
5 N L 28.Apr Douglas Gilbert 65 [PATCH] ide-scsi 2.5.10-dj1 compilation fail 6 N L 27.Apr Martin Dalecki 32 |-> {Cc linux-kernel@vger.kernel.org} 7 N L 27.Apr Martin Dalecki 32 ||=> {Cc linux-kernel@vger.kernel.org} 8 N L 28.Apr Douglas Gilbert 65 |=> {To linux-kernel@vger.kernel.org}
D.h. #6 und #7 sowie #5 und #8 sind identisch (weshalb mutt wohl auch das '=' malt).
Hmm, mutt -> limit -> Pattern: ~= -> loeschen.
Mails werden per fetchmail abgeholt und per exim lokal zugestellt. Das passiert auch nicht immer und auch nicht mit allen Mails. Hat das schon mal jemand erlebt? Hab leider nix dazu finden können.
Vielleicht ein bis zwei am Tag ala: To: user-...@... CC: dev-...@...
wobei ich bei user-... und dev-... eingetragen bin. Procmail und formail koennen doppelte Mails anhand eines Caches von Message-IDs erkennen und filtern. Steht in procmailex(5), auch wenn das nicht das eigentliche Problem loest.
Cheers, Rocco.
lug-dd@mailman.schlittermann.de
-
Bert Lange -
Eric Schaefer -
Hilmar Preusse -
Jens Lorenz -
Rocco Rutte -
Stefan Berthold -
Torsten Werner