procmail
[Top] [All Lists]

Re: how to delay (following) tasks on filtered messages

2005-03-19 15:42:14
Am 2005-03-19 11:51:12, schrieb Professional Software Engineering:

Do you REALLY need it invoked that often?  IOW, is something coming down on 
that notification list really so critical that you need to have it the 
minute it shows up, or wouldn't 15 minutes work just as well (and be less 
of a 90% useless task on your machine).  See your own reference to load on 
your server...

OK, 5-15 Minutes are enough...

which check for
the lockfile and if there is none, download the $SOURCE ?

Why would the fetchmail need to be within a lockfile wrapper?  Seems that 
would still manage to hold up your mail processing.

If there is an incoming message, it will be better to generate a
lockfile, because of the writing the body to a file like

    ~/src.tdautobuild/`date +%s`_sourcename.new

and a possibel parallel access of my script invoked by cron.

Why not create a subdir into which you place files named according to the 
file you want to retrieve.  A cron-invoked script looks to that directory 

This is what I was thing... 

and invokes a retrieval (such as apt-get) for each filename found there, 
deleting the marker file once the file has been downloaded, and progressing 
to the next filename found in that dir (which, FTR, wouldn't be where the 
downloaded files are stored).  The very existance of the files would be 
atomic - they're either there or they are not, and procmail wouldn't be 
writing anything INTO the files, merely creating them, so no lockfile would 
be necessary (save for the invocation of the retrieval script itself).

If procmail write the body of the message to the file above and
my script try to access it, maybe the script run into trouble...

This way, your formail could be invoked whatever number of times, and you 
could match watever number of notification messages that you take action on 
- they'll just get queued up for retrieval.

OK.

Using a cron-invoked script allows for more simplistic error recovery than 
using at - if the script simply doesn't delete the stub file from the 
request directory unless it succeeds, then the next invocation can attempt 
to retrieve it again, without any special retry coding on your part.  With 

OK, 'dpkg-buildpackage' return an "exit status" which I can ise to
change the fileneme from

    ~/src.tdautobuild/`date +%s`_sourcename.new
to
    ~/src.tdautobuild/`date +%s`_sourcename.error       ( $? = 1 )
or
    ~/src.tdautobuild/`date +%s`_sourcename.build       ( $? = 0)

paralel I send an automated message to several people...

at, you'd need to set it up to re-queue the request, and unless you're also 
creating a request file with the at approach, you won't have an automatic 
recovery if the at process dies.  Having the request files also gives you 
an easily viewed "queue", and the file timestamps show when they were added 
to the queue.

It is realy cool what I can do with procmail...

I do not know, how many lines my procmailrc and
its INCLUDERC's has, but they are realy much...

If I think back into my Windows time... :-(
(I have used Windows 3 years 9 month only)

Thanks Sean
Good Night
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>