Peter Pentchev <[EMAIL PROTECTED]> writes:
> On Thu, Dec 28, 2000 at 01:44:34PM +0100, Dag-Erling Smorgrav wrote:
> > Volker Stolz <[EMAIL PROTECTED]> writes:
> > > On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote:
> > > > What are you guys smoking?
> > > *shrug* Can you spell "
On Thu, Dec 28, 2000 at 01:44:34PM +0100, Dag-Erling Smorgrav wrote:
> Volker Stolz <[EMAIL PROTECTED]> writes:
> > On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote:
> > > What are you guys smoking?
> > *shrug* Can you spell "event-driven"? There are ways to do things much
> > m
Volker Stolz <[EMAIL PROTECTED]> writes:
> On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote:
> > What are you guys smoking?
> *shrug* Can you spell "event-driven"? There are ways to do things much
> more elegantly today (see all the references to kevent()).
I choose simple and
On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote:
> What are you guys smoking? Use cron to run a spool scanning job every
> minute or so, and use a lock file to make sure one doesn't start until
> the previous one is done. Note that reliable locking is non-trivial in
> Perl; a q
On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote:
> What are you guys smoking?
*shrug* Can you spell "event-driven"? There are ways to do things much
more elegantly today (see all the references to kevent()).
--
\usepackage[latin1]{inputenc}!
Volker Stolz * [EMAIL PROTECTED] *
What are you guys smoking? Use cron to run a spool scanning job every
minute or so, and use a lock file to make sure one doesn't start until
the previous one is done. Note that reliable locking is non-trivial in
Perl; a quick workaround is to use a lock directory instead (mkdir()
will fail if the
On Thu, Dec 28, 2000 at 02:35:19AM -0800, Peter Wemm wrote:
> This sort of thing is why we added poll(2) and later kqueue(2) support
> for getting notifications on directory changes.. eg: you can get an event
> to tell you that a new file "appeared" in your directory.
See how the l0pht-watch po
On Thu, Dec 28, 2000 at 11:36:50PM +1300, Dan Langille wrote:
> On 28 Dec 2000, at 11:29, Volker Stolz wrote:
>
> > Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille:
> > > What about a daemon signalling a waiting perl script?
> > > Is it an issue if the daemon signals the perl script when it's a
On 28 Dec 2000, at 11:29, Volker Stolz wrote:
> Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille:
> > What about a daemon signalling a waiting perl script?
> > Is it an issue if the daemon signals the perl script when it's already
> > processing? Could a signal be missed?
>
> How about using a
Volker Stolz wrote:
> Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille:
> > What about a daemon signalling a waiting perl script?
> > Is it an issue if the daemon signals the perl script when it's already
> > processing? Could a signal be missed?
>
> How about using a FIFO (maybe in /tmp) and
Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille:
> What about a daemon signalling a waiting perl script?
> Is it an issue if the daemon signals the perl script when it's already
> processing? Could a signal be missed?
How about using a FIFO (maybe in /tmp) and let the daemon printf,echo,cat,.
On 28 Dec 2000, at 10:50, Peter Pentchev wrote:
> Hmm. On second thoughts, I wonder if the sleep/opendir method might
> not work better under temporarily high load - even better than the
> cron-based one. If a bunch of mails arrive at the same time.. hmm
> I should play around with kevent to se
On Thu, Dec 28, 2000 at 12:23:12PM +1300, Dan Langille wrote:
> On 27 Dec 2000, at 19:56, Peter Pentchev wrote:
>
> > On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote:
> > > * Dan Langille <[EMAIL PROTECTED]> [001226 23:50] wrote:
> > > >
> > > > My idea is to have a daemon, or s
On 27 Dec 2000, at 11:25, Jack Rusher wrote:
> > At present the files are created through procmail like this:
> >
> > |/usr/bin/perl $HOME/process_cvs_mail.pl > ~/msgs/$FILE
>
> ...this fragment tells me that you are in control of the process of
> creating these files.
That is correct.
> Th
On 27 Dec 2000, at 19:56, Peter Pentchev wrote:
> On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote:
> > * Dan Langille <[EMAIL PROTECTED]> [001226 23:50] wrote:
> > >
> > > My idea is to have a daemon, or something resembling one, sitting on
> > > the box watching the directory.
On 27 Dec 2000, at 12:53, Peter Pentchev wrote:
> Something like..
> | /usr/bin/perl $HOME/process.pl > ~/msgs/$FILE.tmp && \
> mv ~/msgs/$FILE.tmp ~/msgs/$FILE.cvs
Thanks for that. It's helped me solve a procmail problem I was having.
The files were 600 instead of 640, so I did this:
|/us
I was about to write up a group of suggestions that include the notion
that you could use kqueue to watch the directory's vnode, you could use
Erez's stackable file system code to pass all file creates through a
filter, use lpd's spooling mechanism to treat the incoming directory
like a print q
On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote:
> * Dan Langille <[EMAIL PROTECTED]> [001226 23:50] wrote:
> >
> > My idea is to have a daemon, or something resembling one, sitting on
> > the box watching the directory. When a new file appears, it starts a perl
> > script. T
* Dan Langille <[EMAIL PROTECTED]> [001226 23:50] wrote:
>
> My idea is to have a daemon, or something resembling one, sitting on
> the box watching the directory. When a new file appears, it starts a perl
> script. This perl script is beyound the scope of my question, but it
> processes al
Dear All,
What you'd really want is some kind of message queueing system for this kind
of work. What message queueing systems are (non-commercially) available on
UNIX systems?
Kees Jan
You are only young once,
but you can stay immatur
> > > unlock the file
> > >
> > > The cleaner you mentioned: run it every 15 minutes, compare the
> > > date/time on the lockfile, if more than 15 minutes old, grab the PID,
> > > and kill the job, remove the lock.
> >
> > Correct.
Actually, you can make it a lot better:
If the lockfile exi
On Wed, Dec 27, 2000 at 01:18:28PM +0200, Peter Pentchev wrote:
[snip..]
> closedir(D);
> foreach $fname (@files) {
> next if (($fname eq ".") || ($fname eq ".."));
> # more filename vailidity checks go here
^ validity
On Wed, Dec 27, 2000 at 11:09:40AM +, Mike Bristow wrote:
> On Wed, Dec 27, 2000 at 12:53:37PM +0200, Peter Pentchev wrote:
> > Btw, anybody reading this discussion - I tried the attached script with
> > #!/usr/bin/perl -wT, and Perl died on the unlink() - "unsafe dependency".
> > What gives?
On Wed, Dec 27, 2000 at 12:53:37PM +0200, Peter Pentchev wrote:
> Btw, anybody reading this discussion - I tried the attached script with
> #!/usr/bin/perl -wT, and Perl died on the unlink() - "unsafe dependency".
> What gives?
$ man perldiag
[snip]
Insecure dependency in %s
(F)
On 27 Dec 2000, at 10:11, Mark Murray wrote:
> > Any ideas on how to do this? Any suggestions on the process?
>
> Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
> and if you can't get the lock, die. The file should contain the PID
> of the process that holds the lock, so tha
On Wed, Dec 27, 2000 at 11:17:47PM +1300, Dan Langille wrote:
> On 27 Dec 2000, at 12:11, Peter Pentchev wrote:
>
> > I would do that (and have done it in several projects) using opendir()
> > and readdir(). Open the directory, read entry by entry, when you find
> > a file you want, process it a
> On 27 Dec 2000, at 10:11, Mark Murray wrote:
> >
> > [use flock(2)]
>
> But what part of the solution does flock solve?
It solves the problem of finding out whether the Perl script is
already running, but as I understood the original posting, this isn't
what you were asking. See below.
> I'
On 27 Dec 2000, at 12:11, Peter Pentchev wrote:
> I would do that (and have done it in several projects) using opendir()
> and readdir(). Open the directory, read entry by entry, when you find
> a file you want, process it and unlink() it. Get to the end of the dir,
> sleep, repeat.
Thanks for
On Wed, Dec 27, 2000 at 08:49:51PM +1300, Dan Langille wrote:
> FreshPorts2 will have a new processing strategy for incoming
> messages. Each message will be in a separate file in a predetermined
> directory. As each file arrives, it is processed by a perl script. I want
> only one instance o
On 27 Dec 2000, at 10:11, Mark Murray wrote:
> > Any ideas on how to do this? Any suggestions on the process?
>
> Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
> and if you can't get the lock, die. The file should contain the PID
> of the process that holds the lock, so tha
> Any ideas on how to do this? Any suggestions on the process?
Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
and if you can't get the lock, die. The file should contain the PID
of the process that holds the lock, so that a cleanerd can kill
stuck processes, or so that the lo
FreshPorts2 will have a new processing strategy for incoming
messages. Each message will be in a separate file in a predetermined
directory. As each file arrives, it is processed by a perl script. I want
only one instance of that perl script running at a given time. This is
primarily for se
32 matches
Mail list logo