Note: please don't spam any of the e-mail addresses which you see here. Follow this link if you want some addresses to misuse.
From: Kenneth Tindle <ktindle@uky.edu> Date: Fri, 08 Aug 2003 16:38:06 -0400 Subject: PPR: ppop vs. PPOP.pm saga continues David, Thank you for such patience while dealing with this problem. >This is very intersting. It looks to me like it runs right from the >command line. It does. The correct HTML does get output. >This may means that when run out of Xinetd, the program >is poisoned in some way. The poison either prevents ppop from being >executed or causes it to die stillborn, before it can print any >messages. It dies stillborn. > Possiblities include: > >* Shared library differences >* Resource limits >* Environment variables >* Obscure bugs in PPR, the C libraries, or the kernel triggered by >seemingly irrelevant factors such as whether stdout is a terminal. Excellent summation. Very precise. >Try this as root: > ># ~ppr/lib/ppr-httpd --standalone-port=15011 > >This starts a standalone copy of the PPR HTTP servers on a different >port. Now point your browser at it on port 15011 and see what happens. It does work. >If that works, we have to figure out what is different when it is run >out of Inetd. Do this: > >* Load http://localhost:15010/cgi-bin/test_cgi.cgi in a browser, press >one of the submit buttons, and print out the list of environment >variables which you get. OK. >* do this as root: > ># killall xinetd ># /usr/sbin/xinetd > >This will make programs launched by Xinetd descendents of your shell >instead of more direct children of Init. I actually used the Red Hat-centric "service xinetd stop". But this is nit-picking for sure- this is a terrific method. >* See if the web interface on port 15010 works now. It does. >* If it does, load http://localhost:15010/cgi-bin/test_cgi.cgi again, >press one of the submit buttons, and note how the enviroment is >different. See anything? Yep. The environment variables are very different. Changed: SHLVL - working, "1"; failure, "3" Vars in failed config that do not exist in working config: G_BROKEN_FILENAMES HISTSIZE HOSTDISPLAY HOSTNAME INPUTRC LAMHELPFILE LESSOPEN LS_COLORS MOZILLA_HOME PVM_ROOT PVH_RSH QTDIR SHELL SSH_ASKPASS TRIPPLITE_PAP_HOME USERNAME WINDOWID XPVM_ROOT Vars in working config that do not exist in failed config: LC_COLLATE LC_MONETARY LC_NUMERIC LC_TIME It is as if, when things are working, xinetd is supposed to clean the environment, because if it fails to do so, Perl's IPC module will kill the process. Here's a final killer- in all this, it never occurred to me to restart the xinetd daemon. Now that it has been restarted, the CGI environment is showing shell level 1 and all is well! Is this an installation thing- "make install" needs to restart xinetd as one of the final steps? After a reboot (done for testing purposes here) or an xinetd restart, the original failure cannot be duplicated! Note that I had xinetd running against the 1.50a2 code when I issued the "make install". I noticed that the shell colors were wrong immediately afterwards, such that some filenames could not be seen any longer on a simple "ls -l". Something ugly happened. It actually would be a really terrific idea to manually stop xinetd, upgrade ppr, then start xinetd. Might save some agony. Sigh.