arkturuz has asked for the wisdom of the Perl Monks concerning the following question:

Greetings!

I have a weird problem:
In the last 2-3 weeks Apache server upon calling my CGI application started to write this to a log file: 

[Wed Feb 15 17:09:32 2006] [error] [client 192.168.14.21] script not f
+ound or unable to stat: /some/path/undefined, referer: http://test-se
+rver/cgi_app.pl

[download]
Of course program '/some/path/undefined' does not exist, nor any invocation of a program of that name in my source code (nor in apache config files).
Anywhere!

So I made a little program named 'undefined' and placed it in /some/path. This program appends to a /tmp/some_file.log time of call and arguments passed to a program. After a few execution of a CGI program I get execution times in that file (meaning @ARGV is empty). So now I don't have nasty lines in apache log files :-)

Any hints of what could possibly generate such behaviour in a CGI application?

Replies are listed 'Best First'.
Re: invocation of a ghost file
by ikegami (Patriarch) on Feb 15, 2006 at 16:36 UTC

    @ARGV is always empty for CGI scripts. (Well, it would be set for ISINDEX queries, but noone uses those anymore.) You'd be better off logging $ENV{QUERY_STRING} and $ENV{PATH_INFO}, or even the entire environment.

[reply]
[d/l]
[select]
      I thought that something calls 'undefined' with CL arguments so I decided to print @ARGV (and %ENV).

      But, the problem is what is invoking /some/path/undefined?
      It started when I added a lot of new code, so I believe it is a bug somewhere, but I can't think of a bug which would generate such behaviour. I don't invoke other programs in that CGI app at all.

[reply]

        It wasn't invoked from the command line. If it was, it wouldn't be in your web server's logs.

        The web server attempted to invoke the script, surely via CGI (which is why @ARGV is empty).

        Indirectly, a web client attempted to invoke the script.

        Even more indirectly, and assuming the referrer is accurate, a web browser was redirected there by http://test-server/cgi_app.pl, or a user followed a link outputed by http://test-server/cgi_app.pl.

        That's all that can be known from the information given. Knowing what's the last thing that IP address requested might help you.

[reply]
[d/l]
Re: invocation of a ghost file
by davorg (Chancellor) on Feb 15, 2006 at 16:40 UTC

    Try storing the value of $ENV{HTTP_REFERER} to your log file. That might give some idea of where the program is being called from.

    Update: Ignore me. You've already got the referer. It's in the error log.

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

[reply]
      The referrer is already being logged in the original error message. (And you misspelled ENV.)
[reply]
Re: invocation of a ghost file
by pileofrogs (Priest) on Feb 15, 2006 at 16:39 UTC

    The answer to your question will depend on what cgi_app.pl does, which we dont' know.

    It looks like it's a wrapper of some kind that's calling other scripts, and in some situations it doesn't know what to call. There's a variable that's supposed to hold the name of the script to execute, and whoever wrote cgi_app.pl gave it the value of the string 'undefined' for situations in which it is undefined (aka undef). This would stop it blowing weird errors and possibly dying, but at the expense that you see this odd, somewhat cryptic, behavior...

    The fact that it's calling scripts based on user input fills me with fear that it's not very secure. Make sure that users across the internet cannot execute arbitrary commands.

    --Pileofrogs

[reply]
      I agree with you (I refer to last paragraph) and I have no such program invocation (meaning program invocation based on user input).

      The program SELECTs some data from a database, allows user to edit data (via HTML form input elements), and stores them back to a database.

      This error in log file happens whether I do edit data or not.

      No outer program calls involved.

[reply]

        Ah! Then it's redirecting them to a URL which attempts to execute /some/path/unknown. Look in your access logs for a request for something like test-server/cgi-bin/unknown.

[reply]

Back to Seekers of Perl Wisdom