Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Running a PERL script unattended on a W2K server.

Status
Not open for further replies.

pcutler

Technical User
Jan 18, 2002
59
CA
Hi,

I’ve run into a problem that has me stumped.

I have written a script that checks a directory for a file with tomorrows date in the filename, re-names the file and FTPs the file off the system. It then checks to see if the transfer was successful and sends an e-mail to notify if the transfer worked of if it failed.

The script works great, as long as I’m logged into the system. If I set it up as a scheduled task, the transfer fails because it can’t find the file.

Since the transfer works fine when I’m logged in and fails if I’m not, I’m having trouble tracking down why it’s failing.

Can a Perl script be set to login as a specific user and then run? If so, how would I do this?

The system in question is running Windows 2000 server

Thank you for your time.

PC
 
Where have you stored the perl script?

--------------------------------------------------------------------------
I never set a goal because u never know whats going to happen tommorow.
 
Thanks for your reply.

It's on the "C" drive in a folder called "Scripts"

PC
 
When you are logged in you have a whole variety of environment variables set - enter "set" in a cmd window and you will see them all. When you aren't logged in, these will not be set up and so the script does not have the required environment settings to run successfully.

In your case the issue is probably the 'path' variable, which tells the system where to find perl (probably C:\Perl\bin).

Put the following at the beginning of your script and try running it again from the scheduler:
Code:
use Env ("PATH");
$ENV{PATH}='C:\perl\bin';
If your perl bin is at a different address, just change the second line above to reflect the correct location.
 
Windows Task Scheduler will by default use the System account, which does not have any rights to the network. When you set the job up in TS, set it to use your login account and all should work.
 
PC - I'd be saving everything to a log file, especially error messages and the like.

Everytime you do something check the return code and write a message to the log file if you don't like what happened. This will let you track down where the error is occurring at the very least.

Like this.
Code:
# at the beginning of your script
open(LOGFILE,">c:/logfile.txt") || exit 1;

# and then like this throughout your script
unless( open(SF,"<somefile.txt") {
[tab]# record the error
[tab]print LOGFILE "Problem creating some file, perl reports the following error\n$!\n")
[tab]close LOGFILE;
[tab]exit 1;
}
Hope this helps and isn't just teaching you to suck eggs.

Mike

I am not inscrutable. [orientalbow]

Want great answers to your Tek-Tips questions? Have a look at faq219-2884

 
Thanks for all your input.

After reading through it, I’d like to add a few specifics.

The script is actually running as scheduled, and I do receive a “Fail” e-mail each time it runs unattended.

The file I’m trying to re-name and transfer lives on a mapped network drive and I suspect that this is the source of my problem.

Is it possible to have the script log itself onto the system as the first step in the script? When I set up the scheduled task, I did set it to run as me, but that doesn’t seem to help.

Can a PERL script be set to run as a service, and would that even help?

Again, I thank you for your help. This script is my first attempt at PERL and I’m amazed that I managed to get to this point.

PC
 
Can a PERL script be set to run as a service, and would that even help?

Yes, the Active Perl has a toolkit to do this.

If this is a mapped drive, then there could be permission problems, especially if like a Novell drive.
 
The drive mapping almost certainly isn't available as it's probably mapped during user login. I had a similar situation and used the following at the beginning of the script to create the drive:

Code:
#map drive to \\erdna001\ssp if required
if (chdir 'Z:/CNS') {
	print LOGFILE "Z drive exists\n";
} else {
	`net use Z: $resource $dompword /USER:$domuser`;
	print LOGFILE "Z drive created\n";
}

I needed the Z: drive to be available, so if I could not chdir to it I created the drive mapping, where $resource = \\erdna001\ssp, $dompword = domain password and $domuser = user account.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top