cron job not working

I assume that you are running this on Solaris (yes?)
I assume that you made sure the script was executable (chmod 755 - yes?)

Who is the cron job running 'as'?
What does the actual cron job entry look like (suggest copy/paste - to avoid typos)?

Coding notes:

If you use TeamSite::Config::iwgethome() - you do not need to use chomp() on the return value.

You run a bunch of commands - but you don't check the output from them (granted, iwregen does not currently return any useful status value, but it does return potentially useful text output). You may need to redirect STDERR into STDOUT to capture the full information:

my $results = `... 2>&1`;
if ($results ne "") { ... }

[stylistic]
You should probably learn to use the pragma 'use strict;' and declare your variables with 'my'

--fish
(Interwoven, Curriculum Development)

mogoo

ghoti-
Thank you for your input. I've attached the log of our failed cron job.
We are on Solaris, TSv5.0, the script is chmod 775, and the job is running as IWOV.

Well it's clear from that output that there are problems with the script being run:

A number of stylistic issues - you're not declaring variables with 'my'
Some "Useless use of a variable in void context" warnings
Some "Use of uninitialized value" warnings
A "Can't exec "iwextattr": No such file or directory" Error
A "/default/main/go_intranet/WORKAREA/khan/templatedata/global/postboard/presentation/postboard.tpl: Could not output file: /iwmnt/default/main/go_intranet/WORKAREA/khan/templatedata/global/postboard/data/commsubmit" Error
Some "File or directory is the same as the other version" Errors

Since the script you posted previously does not seem to contain the code being referenced in these errors - you'll have to do your own debugging here - but I suggest you use iwperl -w -c scriptname to help get you started in cleaning up the warnings and errors.

Then, try and run it from the command line to see if it works.

Then, try running it from crontab again.

--fish
(Interwoven, Curriculum Development)

we have same question (TS 5.0.1 on Solaris), but I noticed that the setup of the crontab file was never revisited- did fixing up the perl code rectify the cron invoking issue? is there anything needed in crontab file entry especially to handle the invoke of iw-perl?

we have a script that executes without error from command line (./iw-home/local/bin/ourscript.ipl), but not from a crontab file-

in our crontab file, have tried both of the following:
35 13 * * 1-4 ./projects/iw-home/local/bin/ourscript.ipl
and
35 13 * * 1-4 /projects/iw-home/local/bin/ourscript.ipl

we're running the cron job as root, and permissions are 775, owned by root-
we know the cron is executing because our /var/cron/log file is being appended at the correct time

also, where do you get more info on the -w and -c flags for iwperl CLT? nothing in wf, clt, or admin pdfs, and no man entry in /iw-home/iw-perl/bin ?

The -w and -c switches are standard perl. Try "perldoc perlrun", or look in any perl manual. Basically -w displays warnings and -c checks your code and reports any syntax errors. I like to execute ":!perl -c %" at various times during editing (using vi, of course) to check my syntax along the way.

One thing you can check in your script is whether the "shebang" line is using a relative path to iwperl or a full path. If it's using a relative path, you probably want to change that to a full path.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

I don't know if my previous recommendations fixed the reported problems or not - but if you are experiencing problems with running a script ... you need to debug the differences between when you run it from the command line and when you run it from cron.

In your case - is /projects truly a top-level directory on the file system (i.e. /bin, /usr, /export, /projects)? If so - then the second line you showed (/project/iw-home/local/bin/ourscript.ipl) would be correct - the first line (./projects/...) is bad - don't use relative paths for cron jobs.

You know the script is starting because /var/cron/log is getting updated - good. Do you know what the script is doing? Are you logging its actions in a log file somewhere? If not, that would be my first recommendation.

'-w' and '-c' are standard Perl flags which you can find out about in any reasonable Perl book or running 'iwperl -h'. The '-w' you can actually put into the #! line of the script if you want (somewhat recommended) - the '-c' flag should only be used from the command line as it prevents the script from executing.

--fish
(Interwoven, Curriculum Development)

thanks for the quick responses, both of you-

the shebang line is fully qualified, in that /projects is a top level directory-

will go with the /project/iw-home/local/bin/ourscript.ipl entry in the cron - was trying the leading ".", not to put in relative path, but to run script (i.e. when we invoke all Perl scripts from the command line, must lead with a "./" or they won't run --> does this indicate any problem? like an env setting in Solaris or something? sorry, still refreshing on Solaris a bit)

the script is writing out a log file, though not overwriting the contents when being run from the cron job - the permissions of this log file are 777 owned by root

I will try the iwperl -c -w flags and see if I get some more robust messages about the script itself

mogoo

gsumers-
We haven't gotten our cron job to run properly yet. Like you, we're puzzled, because it runs fine from the command line. What is yours getting stuck on?

Ours attempts to iwregen an html page. Within the tpl of that html page, there's iw_perl logic that removes any expired replicants from the dcr and attempts to rewrite the dcr. It's choking on that step... the log tells us that the tpl could not output (the DCR) file.

Is this anything like what you're attempting to do? Just curious...
maureen

If your log file is not being written to, it looks like you're script is probably not running at all. You might consider a rather bold and time consuming approach. Make a backup copy of your script. Then edit your original script so that it does nothing except open the log file and write a string into it, then closes the log file. See if that works. If not, the script is not running and there must be some permissions issue. If it works, begin adding a little code at a time from the original script until you find the code that makes it stop working. This can be painstaking, especially when testing from cron. I would also set up the cron so your script runs every minute so you don't have to wait very long to see the results.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

running the script from command line via $./iwperl -c /projects/iw-home/local/bin/ourscript.ipl returns a "syntax OK" message-

running the script from command line via $./iwperl -w /projects/iw-home/local/bin/ourscript.ipl runs the scripts successfully without any warning messages and produces the correct results in the UI (multiple active jobs in the workflow ui)

do I need to have the $iwperl directive in the crontab file? i.e. : "35 13 * * 1-4 /projects/iw-home/iw-perl/bin/iwperl /projects/iw-home/local/bin/ourscript.ipl" ? --> adding this changed my output in the cron log (from "< root 23509 c Mon Oct 7 13:35:00 2002 rc=1" to "< root 6460 c Mon Oct 7 15:20:00 2002 rc=2") but can't find documentation on what crontab return code 2 equates to (0 = success and 1 =error, but 2?)?

If the first line in the script is:
#!/projects/iw-home/iw-perl/bin/iwperl
and the script is executable, you should be able to have your cron entry just use:
/projects/iw-home/local/bin/ourscript.ipl
Otherwise, yes, you would have to preface the latter with the former within the crontab file.

I'm not sure why the return code would have changed, but I'd go with the simpler invokation line if possible.

Ultimately it may come down to adding lots of debugging lines into the code, making sure they all get written to some file, and seeing what happens from there.

(note; the reason you had to use './...' on the command line is becuause "." is not in the current user's PATH environment - which is generally correct, especially for 'root' - so you need to explicitly tell it to run something from the current directory [.])

--fish
(Interwoven, Curriculum Development)

smitty-
a good suggestion, when in doubt "deconstruct and isolate"!
I think I've definitely isolated this down to a cron issue, and not a perl issue-
I've deconstructed this perl script down to the very basics, it's complete contents are now:
-----------------------------------
#!/projects/iw-home/iw-perl/bin/iwperl -w

my $gsvar1;
my $gsvar2;

print "hello world\n";
-----------------------------------
and with this code, it still executes nicely from the command line (thank ****!), but not from my cron job-
when running from the cron job, I can't seem to get past "rc = 1" error reported in the var/cron.log -

can some more of the sysadm-y folk out there confirm my cron setup methodology:
1. created text file "our_cron.txt" with following entries:
------------------------------
# To kick off monthly DCFS TeamSite Workflow Jobs - Now set for testing times (all one line, and got same results removing comment line)
20 16 * * * /projects/iw-home/local/bin/utah_dcfs_monthly_wf.ipl (all one one line)
---------------------------------------------------
2. from the location of that txt file, telnet onto our server, su as root, then run $crontab our_cron.txt (the $crontab -e wasn't saving the edits with CTRL-O)

3. verify changes with $crontab -l command to see changes were saved

mogoo-
thanks for the update- I wasn't sure if you had gotten past the "cron aspect" of your problem as well as the "perl aspect"

our script is trying to kick off the same set of jobs (basically a set of periodic "go check the quality of your content" usertasks)- we do a generate step within the workflow also (see Workflow thread titled "iwaddtaskfile path attribute")-

our workflow works fine for all steps when we initiate through "new_job", and it works fine when we initiate it manually through a perl script that is running the iwjobc and iwinvokejob CLTs, but not when we try to kick off that perl script through a cron entry

Perhaps I should phrase this question differently:
Is it possible to invoke a perl script from cron which has the following call to iw-perl in it's shebang declaration:
#!/projects/iw-home/iw-perl/bin/iwperl -w ?

Since we've cut down the perl the bare basics "hello world" function and it still isn't running via cron, it has to be one of two things: our cron setup on our server, or a limitation of iw-perl-

To isolate this as a cron setup problem on our server, I pose the question:
Has anybody else actually utilized this before with success? on TS 5.0.1 on Solaris8- a confirmation would certainly help, though I haven't yet seen anybody on devnet say they've actually done this-

For what it's worth, I use cron a lot in my day-to-day activities, invoking perl in the shebang line, but without the -w switch. No problems like you're having. We've used TS 4.2.1 and 5.5.2 and Solaris 8. I've never had the kind of problems with cron you're having.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

I suggest you use a simpler and better-for-cron type script to test things out:

#!/projects/iw-home/iw-perl/bin/iwperl
if (open(X, ">>/tmp/mydbg.txt")){
   print X "[", scalar(localtime()), "]: Can you hear me now?\n";
   close(X);
}
exit(0);

output to STDOUT from a cron script usually gets captured and sent in email to the owner of the cron process and/or to 'root' on the system - you don't want your script to generate output that way - so it's better to write a test script that lets you verify whether the script is actually running.

--fish
(Interwoven, Curriculum Development)

thanks for the confirmation Dave-
it's good to know that there should indeed be a light at the end of the tunnel- I just hadn't heard anybody speak of it-

now for the useful info:
we removed the -w flag from our shebang line and get same results (rc=1) in our /var/cron/log

going on to test ghoti's suggestion of using other "simple" Perl code in our script

thanks for the heads up on what is "CRON-simple Perl" ghoti-

I replaced all of our code in ourscript.ipl with the snippet you provided, tested it from the command line (successfully) and then set up the crontab again- on the execution of the script via cron, we received the same message in our /var/cron/log (rec=1) and no rewrite of mydbg.txt

so I'm guessing that this (along with Dave's response that this should work) definitely isolates this as a cron setup issue, but unfortunately haven't received any input on this front yet

I think I'm definitely escalating this up to the sysadmin here, and would appreciate if there was somebody else you could think of to query directly on the devnet side? just somebody to compare cron setup with would be very useful now I think

Just as a total shot in the dark, could you try setting up another cron file, but this time owned by you, not root. Try running a couple different simple scripts in this cron, maybe a mixture of perl and shell. See if they work. One thing I remember someone telling me is that because every user can have their own cron, you want to be sure that you initiate your cron as yourself. In other words, if you have a cron owned by you, and you have sudo priviledges, make sure you run your cron like this:

crontab cronjobs

and not this:

sudo crontab cronjobs

Our cron jobs are owned by our "iwoven" user, not root. I don't know the ramifications of running the cron as root, or if there even are any. I'm just grasping at straws here.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

thanks for suggestion smitty-
unfortunately, didn't rectify our problems- I ran crontab under my own login (and not with $su root)
still getting rc=1 on /var/cron/log (though my username was now logged)

I also tried this (running crontab as user other than root) in combination with ghoti's "simple Perl for Cron" example and still got same result-

by the way, you mention a "iwoven" user on your system? do you mean "iwui"? or is this a user account you created seperately from the TeamSite install? I don't find a mention of "iwoven" user in the admin pdf or on our own system (though only 5.0.1)- if so, are you running crons as "iwui"? if so, is it OK to reset password of "iwui" so you can login to server (to run crontab)? this doesn't negatively affect use of iwui by application, etc in any way?

My mistake - I should have been more clear. The "iwoven" account is one that we set up - not to be confused with "iwui". We don't mess with the "iwui" account. We have sudo access via the iwoven account. Also, the cron is run from the iwoven account. Sorry for the confusion.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com