Hi,
I’ve got a bunch of scripts that suddenly appear to be dying on me. When
I run them in my Ruby editor, Aracho, they run fine. But, when they’re
scheduled with a scheduler and run on their own every ten minutes or so,
they run the first part of the script, but then stop. Here’s a simple
sample of one os these scripts. They’re basically just conversion
scripts. They convert EPS or PDF files to two formats, TIFF and PNG,
and, once that’s done, they copy and move those files to various places
on my network.
The script dies right after it finishes with line 5 here. All the files
created simply stay in the scratch directory and aren’t moved or copied.
1 Dir.chdir(“C:/prodalchemy/IM/scratch”)
2 Dir.glob("*.eps").each do |epsfile|
3 Alchemy.tiff epsfile
4 Alchemy.png epsfile
5 end
6 Dir.chdir(“C:/prodalchemy/IM/scratch”)
7 #EPS Files
8 epsfiles = Dir.glob("*.eps")
9 epsfiles.each do |epsfile|
10 FileUtils.cp(epsfile, “E:/out2ps2k/print”)
11 FileUtils.cp(epsfile, “E:/out2vax”)
12 prefix = epsfile[/[A-z-]{1,6}/]
13 numerals = epsfile[/[0-9]{1,6}/]
14 epsdirectory = “”
15 if numerals.to_s.length == 6 then
16 prime = numerals[0,3]
17 epsdirectory = “//vigil/eps/#{prime}000”
18 elsif numerals.to_s.length == 5 then
19 prime = numerals[0,2]
20 epsdirectory = “//vigil/eps/#{prime}000”
21 elsif numerals.to_s.length == 4 then
22 prime = numerals[0,1]
23 epsdirectory = “//vigil/eps/0#{prime}000”
24 elsif numerals.to_s.length == 3 then
25 epsdirectory = “//vigil/eps/00000”
26 elsif numerals.to_s.length == 2 then
27 epsdirectory = “//vigil/eps/00000”
28 elsif numerals.to_s.length == 1 then
29 epsdirectory = “//vigil/eps/00000”
30 end
31 FileUtils.mv(epsfile, epsdirectory)
32 end
It repeats this “EPS” clause for PDF, TIFF, and PNG, too.
I’ve got a bunch of scripts that suddenly appear to be dying on me. When
I run them in my Ruby editor, Aracho, they run fine. But, when they’re
scheduled with a scheduler and run on their own every ten minutes or so,
they run the first part of the script, but then stop. Here’s a simple
Did you consider that they might take longer than ten minutes and
subsequent executions interfere with each other? Depending on what
scheduler you use the reason for the slowness could be low process
priority.
It’s probably a good idea to do two things: add a mechanism that will
prevent concurrent executions of the same script and add logging.
I’ve got a bunch of scripts that suddenly appear to be dying on me. When
I run them in my Ruby editor, Aracho, they run fine. But, when they’re
scheduled with a scheduler and run on their own every ten minutes or so,
they run the first part of the script, but then stop. Here’s a simple
Did you consider that they might take longer than ten minutes and
subsequent executions interfere with each other? Depending on what
scheduler you use the reason for the slowness could be low process
priority.
It’s probably a good idea to do two things: add a mechanism that will
prevent concurrent executions of the same script and add logging.
Kind regards
robert
Well, if you look at the above, all of the image processing happens
before any file movement. So, all the files are created, then, they’re
told to move.
What do you mean by concurrent executions of the same script? My
scheduler doesn’t allow the script to run if it’s already running.
Thanks.
Well, if you look at the above, all of the image processing happens
before any file movement. So, all the files are created, then, they’re
told to move.
Accessing a resource concurrently in a not read only manner has always
potential for surprising behavior. So it’s best to take measures to
prevent it.
What do you mean by concurrent executions of the same script? My
scheduler doesn’t allow the script to run if it’s already running.
Did you verify that it actually behaves as expected? Even if it does
behave as expected it might be a good idea to make your script more
robust by adding a mechanism that prevents concurrent execution of the
script. You might change your scheduler at one day and the other one
does not prevent this etc.
Well, my glass bowl is in repair at the moment so I am afraid you will
have to debug this yourself. Without diagnostic output nobody here
can explain what’s happening.
Cheers
robert
Aaaaaaah. My scheduler is set to run every 5 minutes. The first thing
the script does is copy the files to a sub-directory, so, even if the
thing executed again within those 5 minutes, there are no files in the
source directory to act on, so, it doesn’t execute. What’s so
frustrating is that this thing executes just fine in my editor. It works
perfectly. What’s the difference between running it in an editor and
having it run as a scheduled event?
Well, if you look at the above, all of the image processing happens
before any file movement. So, all the files are created, then, they’re
told to move.
Accessing a resource concurrently in a not read only manner has always
potential for surprising behavior. So it’s best to take measures to
prevent it.
What do you mean by concurrent executions of the same script? My
scheduler doesn’t allow the script to run if it’s already running.
Did you verify that it actually behaves as expected? Even if it does
behave as expected it might be a good idea to make your script more
robust by adding a mechanism that prevents concurrent execution of the
script. You might change your scheduler at one day and the other one
does not prevent this etc.
Well, my glass bowl is in repair at the moment so I am afraid you will
have to debug this yourself. Without diagnostic output nobody here
can explain what’s happening.
Aaaaaaah. My scheduler is set to run every 5 minutes. The first thing
the script does is copy the files to a sub-directory, so, even if the
thing executed again within those 5 minutes, there are no files in the
source directory to act on, so, it doesn’t execute.
Your statement is contradictory. Are files copied or moved?
What’s so
frustrating is that this thing executes just fine in my editor. It works
perfectly. What’s the difference between running it in an editor and
having it run as a scheduled event?
You know what’s frustrating me? You keep on asking the same thing
over and over again and expect answers while nobody knows your
environment and you do not give details. As far as I can see you did
neither mention operating system, ruby version, the type of scheduler
you are using etc. How can you expect us to give reasonable answers
to “it does not work - why?” type of questions? Why don’t you add
some logging statements to your script as I suggested to see what it
is doing?
Aaaaaaah. My scheduler is set to run every 5 minutes. The first thing
the script does is copy the files to a sub-directory, so, even if the
thing executed again within those 5 minutes, there are no files in the
source directory to act on, so, it doesn’t execute.
Your statement is contradictory. Are files copied or moved?
What’s so
frustrating is that this thing executes just fine in my editor. It works
perfectly. What’s the difference between running it in an editor and
having it run as a scheduled event?
You know what’s frustrating me? You keep on asking the same thing
over and over again and expect answers while nobody knows your
environment and you do not give details. As far as I can see you did
neither mention operating system, ruby version, the type of scheduler
you are using etc. How can you expect us to give reasonable answers
to “it does not work - why?” type of questions? Why don’t you add
some logging statements to your script as I suggested to see what it
is doing?
I’m very sorry. You’re right. I’m on Windows XP, 32-bit. Ruby 1.8.6. The
scheduler I use is Splinterware’s System Scheduler. It’s set up to only
execute when there are files in the source directory. Like I said above,
the first thing my script does is move the input files. So, it’s very
rare that there would be new files in the input directory the next time
it’s scheduled. But, even if there were, it should kick off a new
instance of the script.
The script executes fine until it gets to the part where it’s supposed
to copy and move the files, using FileUtils.
It works perfectly in the editor, like I said, and, it works perfectly
when run from the command shell.
Robert K. wrote:
(…)>
I’m very sorry. You’re right. I’m on Windows XP, 32-bit. Ruby 1.8.6. The
scheduler I use is Splinterware’s System Scheduler. It’s set up to only
execute when there are files in the source directory. Like I said above,
the first thing my script does is move the input files. So, it’s very
rare that there would be new files in the input directory the next time
it’s scheduled. But, even if there were, it should kick off a new
instance of the script.
The script executes fine until it gets to the part where it’s supposed
to copy and move the files, using FileUtils.
It works perfectly in the editor, like I said, and, it works perfectly
when run from the command shell.
This system scheduler uses the LocalSystem account (by default). Does
this account have access to both the source and target folders?
hth
Siep
Good point. No, I have it set to use a network account that has rights
to all necessary drives. It’s the user that’s auto-logged in on that PC.
The same user using the editor and the command shell.
Robert K. wrote:
(…)>
I’m very sorry. You’re right. I’m on Windows XP, 32-bit. Ruby 1.8.6. The
scheduler I use is Splinterware’s System Scheduler. It’s set up to only
execute when there are files in the source directory. Like I said above,
the first thing my script does is move the input files. So, it’s very
rare that there would be new files in the input directory the next time
it’s scheduled. But, even if there were, it should kick off a new
instance of the script.
The script executes fine until it gets to the part where it’s supposed
to copy and move the files, using FileUtils.
It works perfectly in the editor, like I said, and, it works perfectly
when run from the command shell.
This system scheduler uses the LocalSystem account (by default). Does
this account have access to both the source and target folders?
hth
Siep
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.