in reply to file open problem with scheduled jobs

I suspect the problem is that you are specifying a relative path ie file.log and expecting that after the detach you will still be in the same dir. You are not. Like all good daemons Schedule::Cron is doing a chdir '/' (so you can unmount parts if the FS) ie: 

} else {
      # Child:
      # Try to detach from terminal:
      chdir '/';   # <---
      open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
      open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!";

[download]

As a result if you are in /some/dir and try to write to file.log when you don't detatch you are trying to write /some/dir/file.log whereas after detaching you you would try to write /file.log ie in root where user nobody won't have perms. I further suspect that you are not checking the return value of your open, because with STDERR still open you should be seeing the permission denied message. 

open F, ">$fully_qualified_path" or die "Can't write $fully_qualified_
+path $!\n";

[download]

FWIW This module has not been updated since 2000 so the author appears to have lost interest given there is a TODO list. No reason not to use it and the code looks well sorted, just don't expect any new features anytime soon.

cheers

tachyon

Replies are listed 'Best First'.
Re: file open problem with scheduled jobs
by nmete (Novice) on Jul 22, 2004 at 14:57 UTC
    Firstly thanks for your help... yes, the problem was with the file paths and it works with the absolute path.

    but I am still confused of following:
    my $filename1 = "/var/apache/cgi-bin/user/test.txt";
    my $filename2 = "http://my_site/cgi-bin/user/test.txt";

    open(HANDLE,">$filename") or die "couldnt open $filename for writing $!";

    open function works well with the filename1 but not with filename2.
    What is the difference?
[reply]
      $filename1 is a unix filesystem path, which is the way that the file *really* is addressed.

      $filename2 is a web address. The web server translates the web address into a unix filesystem filename, based on how you have the web server configured. http://my_site/ is the web address of the web server, the next part, /cgi-bin/, is probably your cgi root, which is set up in your web server configuration, and translates to some absolute base path, in your case it appears to be /var/apache/cgi-bin/. The rest, user/test.txt refers to a specific file on that server.

      So the web server filename translation changes your address to /var/apache/cgi-bin/user/test.txt, which is exactly what $filename1 is.

      So, after all that, the web server automatically does that translation, but perl assumes that you are giving a relative or absolute pathname that is of the form your operating system normally deals with, i.e. it doesnt do the translation that the web server does. If you're much into unix, think about why a command like rm $filename2 wont work right. perl assumes filenames just like the unix shell does.

      The reasons for the web address translation are many, it allows virtual hosting, and it also keeps me from doing something like http://your_server/etc/passwd - which you probably dont want me doing.

      You should probably read up on apache & web server conifguration in general.

[reply]
        OK... what I missed out was, once I scheduled the job then it is not running on any http server.. so there was no web server to do the address translation that I expected...
        thanks
[reply]

In Section Seekers of Perl Wisdom