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