when run from cron, regex NEVER match, always give nil

[James Dinkel]

I'm using ruby 1.8.6 on RHEL 5.3. I also had this problem with ruby
1.8.5 that comes with RHEL. I had hoped the ruby upgrade would fix it
but it didn't.

Anyway, no regexps will match, even the most blatant matches, when the
script is run from cron.

A line like '/.*/.match("myrandomstring")' matches just fine when the
script is run from the console, but it returns nil when run from cron.
And that regex should match ANYTHING.

I'm not sure if this is an issue with ruby or if it is something with
cron, but I really need regex's to work from cron scripts. Help?

 

[Tim Hunter]

I'm using ruby 1.8.6 on RHEL 5.3. I also had this problem with ruby
1.8.5 that comes with RHEL. I had hoped the ruby upgrade would fix it
but it didn't.

Anyway, no regexps will match, even the most blatant matches, when the
script is run from cron.

A line like '/.*/.match("myrandomstring")' matches just fine when the
script is run from the console, but it returns nil when run from cron.
And that regex should match ANYTHING.

I'm not sure if this is an issue with ruby or if it is something with
cron, but I really need regex's to work from cron scripts. Help?

It's cron. Or rather, it's not cron, or Ruby, but something about the
environment that cron sets up to run your script.

Think about it. A Ruby program doesn't "know" that it's being run from
cron. It just runs. There's nothing in Ruby that says "Oh, I've been
invoked from cron, so I need to do things differently." Ruby scripts
always do the same thing no matter how they're invoked. Regexps match,
or don't match, no matter how you invoke the Ruby script.

Therefore something about the environment that is present when cron runs
your script is different than you expect. You don't say how you know
that the regexp doesn't match. What symptom of failure do you have?

99% of all cron problems are caused by PATH differences. Remember cron
uses a different PATH than you have in your personal shell. You may have
to specify the full path to Ruby, or something like that. See
http://unixgeeks.org/security/newbie/unix/cron-1.html for some more info.

 

[Xeno Campanoli]

It probably has something to do with the cron not using Bash as the default
shell, though why this would affect Ruby, I fail to understand. I ran into this
before though. On Debian flavor machines especially a more Bourneshell-shell
like minimalist shell is used as the default instead of Bash, and you end up
getting it as your shell in at, and I think Cron. Is it possible your regex
stuff is somehow getting stuff from a point in the shell that could lose the
data if it were not Bash?

 

[g_f]

Like Tim said, it's probably something in the environment. Besides
PATH, you could have other environment variables set in your BASH
startup that are not set when the default /bin/sh gets started.

For apps I have to run from cron, if I need to, I'll write a
wrapping .sh script that sets up the environment exactly as I need it.
That could include switching to bash/csh/zsh or whatever, or
sourcing .login or .profile or manually setting variables. Cron is
stupid and does exactly what is said plus whatever (hidden) defaults
the system has set up, so figuring it out can be a real task.

I wonder if you might have installed some libraries in your own space
instead of the system's Ruby space. User permission problems will crop
up then and can be a pain to figure out. I'd debug that by logging in
as whatever user the cron job runs as, then manually run the script.

You don't say whether your job is running out of your own user's cron,
or out of root's cron, or via the system's /etc/crontab. For my
production code I set up the scripts to be run as root, but that's
because I've been doing this so long I've shot off most of my toes and
learned the hard lessons about what not to do... I'm sufficiently
paranoid so I'm considered a trusted user.

 

[James Dinkel]

Like Tim said, it's probably something in the environment. Besides
PATH, you could have other environment variables set in your BASH
startup that are not set when the default /bin/sh gets started.

For apps I have to run from cron, if I need to, I'll write a
wrapping .sh script that sets up the environment exactly as I need it.
That could include switching to bash/csh/zsh or whatever, or
sourcing .login or .profile or manually setting variables. Cron is
stupid and does exactly what is said plus whatever (hidden) defaults
the system has set up, so figuring it out can be a real task.

I wonder if you might have installed some libraries in your own space
instead of the system's Ruby space. User permission problems will crop
up then and can be a pain to figure out. I'd debug that by logging in
as whatever user the cron job runs as, then manually run the script.

You don't say whether your job is running out of your own user's cron,
or out of root's cron, or via the system's /etc/crontab. For my
production code I set up the scripts to be run as root, but that's
because I've been doing this so long I've shot off most of my toes and
learned the hard lessons about what not to do... I'm sufficiently
paranoid so I'm considered a trusted user.

sorry for the silence, I've been swamped today (consultants are here
doing a networking hardware upgrade). However, I was incorrent in that
'/.*/.match("myrandomstring")' does actually return a match when run
from cron, but my actual regex is a bit more complicated. My actual
regex does match when run manually though.

I think I'm going to do a little more testing and cut some parts out of
the regex to find if maybe there is just a single unit of the expression
that is the problem. It's a tedious pain in the rump, though since it
matches when run manually, I have to make a change, check the time, set
it to run in a minute from cron, wait for it to run, check the output
file... very tedious and time-consuming.

This is run by root's cron by the way. I don't how to do "sourcing
login or .profile" but I did try making a wrapper script with a
/bin/bash hashbang that then just calls the ruby script, and that didn't
make any difference.

 

[Ray Baxter]

[Note: parts of this message were removed to make it a legal post.]

How exactly do you know that your regular expression doesn't match?
It's more likely your program is matching, but that your output is not going
where you expect. Cron output goes to the user. Since you are running this
as root, are you reading root's mail?

Create a ruby program like, cron_test.rb

if /.*/.match("myrandomstring")
raise "Matched"
else
raise "No match"
end

and then in your crontab

*/5 * * * * /path/to/ruby /other/path/to/cron_test.rb

wait 10 minutes and then read root's mail.

Ray

 

[Ryan Davis]

sorry for the silence, I've been swamped today (consultants are here
doing a networking hardware upgrade). However, I was incorrent in
that
'/.*/.match("myrandomstring")' does actually return a match when run
from cron, but my actual regex is a bit more complicated. My actual
regex does match when run manually though.

I think I'm going to do a little more testing and cut some parts out
of
the regex to find if maybe there is just a single unit of the
expression
that is the problem. It's a tedious pain in the rump, though since it
matches when run manually, I have to make a change, check the time,
set
it to run in a minute from cron, wait for it to run, check the output
file... very tedious and time-consuming.

This is run by root's cron by the way. I don't how to do "sourcing
.login or .profile" but I did try making a wrapper script with a
/bin/bash hashbang that then just calls the ruby script, and that
didn't
make any difference.

I can almost guarantee it has nothing to do with cron itself.

You can start to isolate your problems in a couple of ways. One thing
I use is:

alias newshell='env -i $SHELL --norc'

that brings up a new shell in your terminal that is about as virginal
and bare as what cron runs with.

Another is to set up a side cron task like:

* * * * * /usr/bin/ruby -e 'p /.*/.match("myrandomstring")'

and wait for the mail landslide to start (or tack on 2>&1 >> /tmp/
cron.wtf)

From there, build it up until you can replicate your problem
properly. Pathing, system calls, tainting/SAFE modes... whatever it is
that is actually tripping you up. Find it.

Good luck.