Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 23 Oct 2002 14:39:51 +0200 From: Thomas Baker To: cygwin AT cygwin DOT com Subject: Re: Cygwin/Procmail stops working after setup.exe upgrade Message-ID: <20021023123951.GA2056@LEPIDUS> Mail-Followup-To: Thomas Baker , cygwin AT cygwin DOT com References: <20021022114820 DOT GA2348 AT LEPIDUS> <20021022212639 DOT A31592 AT ms> <20021023091534 DOT GA2040 AT LEPIDUS> <20021023111614 DOT GB1776 AT tishler DOT net> <20021023114319 DOT GA1304 AT LEPIDUS> <20021023122523 DOT GE1776 AT tishler DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021023122523.GE1776@tishler.net> User-Agent: Mutt/1.4i Jason, > If fetchmail is running under your account, then I'm at a loss to explain > your observed behavior. I always start fetchmail by hand as "tbaker" (my account) in a console window with the command "fetchmail --nodetach". My .fetchmailrc says (using ***** to block out the names and passwords): | set daemon 10 | set logfile /cygdrive/e/u/config/fetchmail.log | set invisible # suppress "Received:" line fetchmail adds | set no bouncemail | poll ******* | protocol: pop3 | username: ****** | password: ****** | nokeep | fetchall | # messages | mda "/usr/bin/procmail -d %T" # pass message to the local MDA This last line worked just fine for several months, until the latest upgrade. The command executed is: -rwxr-xr-x 1 tbaker None 61952 Aug 19 16:41 /usr/bin/procmail > Is fetchmail running under the LocalSystem account? If so, then perform > the following: > > chmod 777 e:/u/procmail I don't think it is running under a LocalSystem account, but I tried the above anyway and it did not work. In short, fetchmail is fetching the mail but something seems to be wrong with the handover to Procmail and everything is simply landing in the default /var/spool/mail/tbaker. I assume Procmail is not getting the mail at all because if it were there should be some record of that in the procmail.log. Moreover, I know that Procmail itself is working because "procmail -m" successfully processed the recipes there and recorded that success in the file procmail.log. Tom On Wed, Oct 23, 2002 at 08:25:23AM -0400, Jason Tishler wrote: > On Wed, Oct 23, 2002 at 01:43:19PM +0200, Thomas Baker wrote: > > On Wed, Oct 23, 2002 at 07:16:14AM -0400, Jason Tishler wrote: > > > What *exactly* does procmail.log indicate happened to the misfiled > > > messages? > > > > Attached is the entire procmail.log -- i.e., the log > > captures the file tested with "cat test.mbox | procmail -m > > e:/.procmailrc" (above), but does not register any of the > > incoming mail that is constantly arriving, which all simply > > goes to the default /var/spool/mail/tbaker. > > See below... > > On Wed, Oct 23, 2002 at 10:56:48AM +0200, Thomas Baker wrote: > > On Tue, Oct 22, 2002 at 08:14:52AM -0400, Jason Tishler wrote: > > > I would check the permissions of $PMDIR, $PMDIR/procmail.log, and > > > your entire $MAILDIR tree. > > > > [snip] > > > > $PMDIR: > > drwxr-xr-x 2 tbaker None 4096 Oct 23 10:44 e:/u/procmail > > > > Are these permissions set as they should be? > > Is fetchmail running under the LocalSystem account? If so, then perform > the following: > > chmod 777 e:/u/procmail > > Can procmail write to e:/u/procmail/procmail.log when driven by > fetchmail now? If so, does it indicate why procmail can't write to your > mail folders? > > If fetchmail is running under your account, then I'm at a loss to explain > your observed behavior. -- Dr. Thomas Baker Thomas DOT Baker AT bi DOT fhg DOT de Institutszentrum Schloss Birlinghoven mobile +49-171-408-5784 Fraunhofer-Gesellschaft work +49-30-8109-9027 53754 Sankt Augustin, Germany fax +49-2241-144-2352 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/