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

I am putting together a QA system for our company. I'm using LyX to edit the individual documents, and perl (CGI) scripts to pull it together and do the housekeeping.

One of the jobs I am trying to script is regenerating the whole manual when method statements/procedures have been reissued. I can generate a LyX file with embedded references to all the other LyX files (around 200 of them). Then I want to run "lyx -e latex" against this file to generate LaTeX files to run pdflatex and latex2html against to recreate a PDF and web-site of the whole system.

This works manually. And it works if I run a perl-script from the command-line that calls these commands. But if I try to call the script from a web browser, "lyx -e latex" stalls and the script never returns. I have to kill -9 the lyx process to get rid of the script process.

I don't think it's an ownership/permissions issue. I have created a minimal script that just chdir's to the relevant directory, and then calls lyx -e latex against the relevant file. I can su to the user that apache runs as and call the script, and it runs fine. But if I call the identical script from the browser, it stalls as described. I think the above also indicates it's not a tainting issue (everything is hardcoded - no parameters are passed in this stripped-down script).

I have tried the various ways of calling lyx (backticks, system with list, system with whole command passed as single parameter, fork + exec) and it doesn't make any difference. I have tried calling lyx.bin instead of lyx (which is just a shell wrapper on my system). Of course, I use full paths for the binary and file.

There is no problem if the file called does not contain many embedded files. The problem started when the number of embedded files reached a critical point.

When you run lyx -e latex against a LyX file containing references to embedded files, it seems to run the command against the embedded files as well as the main file. I can tell from looking at the file modification times exactly where the script stalled. It processes around 30 embedded files before stalling. I can run lyx -e latex against the last file to be processed, or any of the succeeding ones without problem, so I don't think it's problems with the individual files.

I am suspicious that it runs out of resources of some sort, but I have no idea what resource constraints there might be on perl called from a CGI-script (not mod_perl) that didn't apply to perl called from the command line.

Sorry for the long explanation, but I wanted to get all the facts in. Does anyone have any ideas why "lyx -e latex" on a file with many embedded children would stall when called from a perl CGI-script? Thanks, Bruno

  • Comment on Calling "lyx -e latex" from perl CGI-script

Replies are listed 'Best First'.
Re: Calling "lyx -e latex" from perl CGI-script
by sgifford (Prior) on Jul 03, 2003 at 05:59 UTC

    Can you look in your Web server's error log to see what error message you're getting?

    If it's a resource issue, running 

      ulimit -a

    [download]
    from your Perl script or a short shell script run as a CGI program might give you some insight.

    In fact, why don't you run this as a CGI script and see what you get? 

    #!/bin/sh -x

printf "Content-type: text/plain\n\n"
exec 2>&1
id
ulimit -a
env

    [download]
    This often gives me great clues in fixing CGI scripts.

    Another trick is to write a short wrapper for your script to see what errors it's getting: 

    #!/bin/sh -x

printf "Content-type: text/plain\n\n"
exec 2>&1
/path/to/your/CGI/script

    [download]
    Installing this as a CGI script and running it will display all output from your program in plain text format, including any errors it generates.
[reply]
[d/l]
[select]
Re: Calling "lyx -e latex" from perl CGI-script
by tilly (Archbishop) on Jul 03, 2003 at 04:58 UTC
    One possible problem is that CGI scripts often start with a different environment than a user. Even after an su, you might not have the right environment.

    I would look to see what $ENV{PATH} is, and see if lyx is in the appropriate path.

    Also look in your server's error log and see if you have a useful debugging message there.

[reply]

      I had set $ENV{PATH} in one of the versions of the stripped down script, because I had tried setting the script to setuid root (to see if it was a permissions issue), which forced it into taint mode, which required a manually-set PATH to allow a system call. I had set $ENV{PATH} to include the same directories as are in root's or the apache user's PATH, both of which can successfully call the script (without the PATH line) from the command line. So I don't think it is a PATH issue, but it's a good try.

      Cheers,

      Bruno

[reply]
        $ENV{PATH} is but one possible environment problem problem. Study %ENV for any differences and see if eliminating them makes the problem go away. For instance LD_LIBRARY_PATH controls finding dynamically loaded libraries on several versions of Unix - that can definitely affect whether lyx can run. It might also want to talk to an X server, which means that things like DISPLAY might be needed. And so on.

        Also you don't say whether or not you looked in your server's error logs. If you haven't done so then replying to people here and getting further rounds of guesses is pretty pointless. We can think of a million things that could go wrong. The server's error logs give you feedback on what is wrong.

[reply]
Re: Calling "lyx -e latex" from perl CGI-script
by fglock (Vicar) on Jul 03, 2003 at 01:25 UTC

    I don't know if it helps, but did you try with '&' ?

    lyx -e latex &
[reply]
[d/l]

      Sorry not to reply sooner. I lost my phone lines and internet connection shortly after sending the question. They're still not back on, which is why I am sending this from a new login from work.

      No, I haven't tried using "&" to put the system call into the background. As the main script stalls while waiting for the system call to return, I'm not sure how putting the command into the background will help.

      Thanks for the thought. I might give it a go, but I'm not optimistic it will help.

      Cheers,

      Bruno

[reply]

Back to Seekers of Perl Wisdom