Hey DM,
I was playing with PHP today, and I couldnt get php-cgi to work with a simple php file.
In web/root I have a simple php file:
root@48b41d63d7ae:/opt/sbbs# cat web/root/x.php
<?php echo phpinfo(); ?>
I set up PHP-CGI according to the wiki and it executes the x.php file:
3/4 13:42:19 web 0030 Request: GET /x.php HTTP/1.1
3/4 13:42:19 web 0030 Executing CGI: /opt/sbbs/web/root/x.php
3/4 13:42:19 web 0030 CGI Process x.php still alive on client exit
3/4 13:44:20 web 0030 Session timeout due to inactivity (120 seconds)
3/4 13:44:20 web 0030 HTTP connection accepted from: 10.1.3.130 port 62868
There are two problems:
1) The CGI executes, but the start of the output includes the terminal server, so the browser doesnt render it properly:
3/4 13:44:43 web 0030 Using handler /usr/bin/php-cgi to execute /opt/sbbs/web/root/x.php
[Threads: 14 Sockets: 19 Clients: 1 Served: 20 Errors: 52] (?=Help): Content-type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<style type="text/css">
body {background-color: #fff; color: #222; font-family: sans-serif;}
2) The script runs until the timeout - it should exit after the echo, but doesnt.
Am I missing anything?
Are you saying that "[Thread: 14 ..." gets send over HTTP? That would be really weird.
Yeah, but off hand I can't say what. For one, I run sbbs daemonized and it appears you aren't. Maybe there's a difference there.
Re: PHP-CGI
By: Digital Man to alter ego on Tue Mar 03 2020 09:28 pm
Are you saying that "[Thread: 14 ..." gets send over HTTP? That would be really weird.
Yes.
Yeah, but off hand I can't say what. For one, I run sbbs daemonized and it appears you aren't. Maybe there's a difference there.
What would that be a difference?
Are you saying that "[Thread: 14 ..." gets send over HTTP? ThatYes.
would be really weird.
Re: PHP-CGI
By: Digital Man to alter ego on Wed Mar 04 2020 10:22 am
Are you saying that "[Thread: 14 ..." gets send over HTTP? ThatYes.
would be really weird.
So is there a fix for this?
I have no idea what the cause is, so I can't fix it yet. Did you try any other CGI scripts (non-PHP)?
Re: PHP-CGI
By: Digital Man to alter ego on Wed Mar 04 2020 10:55 pm
I have no idea what the cause is, so I can't fix it yet. Did you try any other CGI scripts (non-PHP)?
So yes, I've tried a perl script and a bash script.
Each run for MaxCgiInactivity before rendering output.
Each script just echos "Hello World",
.pl:
#!/usr/bin/perl
print "Hello World\n";
## console ##
3/5 20:46:22 web 0035 Request: GET /x.pl HTTP/1.1
3/5 20:46:22 web 0035 Executing CGI: /opt/sbbs/web/root/x.pl
3/5 20:48:22 web 0035 CGI Process x.pl still alive on client exit
3/5 20:48:24 web 0035 CGI Process x.pl did not send data header termination 3/5 20:48:24 web 0035 !ERROR: 500 Internal Server Error (line 5885)
3/5 20:48:25 web 0035 Session thread terminated (0 clients, 2 threads remain, 12 served)
## output ##
[deon@d-1-1 ~]$ curl http://d-1-1.ipv4.leenooks.vpn:8888/x.pl
3/5 20:46:22 web 0035 Using handler /usr/bin/perl to execute /opt/sbbs/web/root/x.pl
<HTML>
<HEAD>
<!-- $Id: 500.html,v 1.4 2005/09/12 00:15:19 deuce Exp $ -->
<TITLE>Internal Server Error</TITLE>
</HEAD>
<BODY>
Internal Server Error!
</BODY>
</HTML>
.sh:
#!/bin/sh
echo "Hello World!"
## console ##
3/5 20:49:11 web 0035 HTTP connection accepted from: 10.1.3.11 port 51818 3/5 20:49:11 web 0035 Request: GET /x.sh HTTP/1.1
3/5 20:49:11 web 0035 Executing CGI: /opt/sbbs/web/root/x.sh
3/5 20:51:11 web 0035 CGI Process x.sh still alive on client exit
3/5 20:51:13 web 0035 CGI Process x.sh did not send data header termination 3/5 20:51:13 web 0035 !ERROR: 500 Internal Server Error (line 5885)
3/5 20:51:14 web 0035 Session thread terminated (0 clients, 2 threads remain, 13 served)
## output ##
[deon@d-1-1 ~]$ curl http://d-1-1.ipv4.leenooks.vpn:8888/x.sh
3/5 20:49:11 web 0035 Using handler /bin/bash to execute /opt/sbbs/web/root/x.sh
<HTML>
<HEAD>
<!-- $Id: 500.html,v 1.4 2005/09/12 00:15:19 deuce Exp $ -->
<TITLE>Internal Server Error</TITLE>
</HEAD>
<BODY>
Internal Server Error!
</BODY>
</HTML>
.php:
<?php
echo "Hello World!";
## console ##
3/5 20:57:59 web 0035 HTTP connection accepted from: 10.1.3.11 port 52608 3/5 20:57:59 web 0035 Request: GET /x.php HTTP/1.1
3/5 20:57:59 web 0035 Executing CGI: /opt/sbbs/web/root/x.php
3/5 21:00:00 web 0035 Session timeout due to inactivity (120 seconds)
3/5 21:00:01 web 0035 Session thread terminated (0 clients, 2 threads remain, 14 served)
## output ##
[deon@d-1-1 ~]$ curl http://d-1-1.ipv4.leenooks.vpn:8888/x.php
3/5 20:57:59 web 0035 Using handler /usr/bin/php-cgi to execute /opt/sbbs/web/root/x.php
[Threads: 15 Sockets: 26 Clients: 1 Served: 14 Errors: 69] (?=Help): Content-type: text/html; charset=UTF-8
Hello World!
Okay, so whatever the problem is, it's not specific to php-cgi. Have you tried running sbbs daemonized? How are you invoking sbbs, exactly?
It's very strange and unexpected that the stdout of sbbs would be sent over the HTTP server. If you run "sbbs -d" instead, how does it behave?
Re: PHP-CGI
By: Digital Man to alter ego on Thu Mar 05 2020 11:17 am
Okay, so whatever the problem is, it's not specific to php-cgi. Have you tried running sbbs daemonized? How are you invoking sbbs, exactly?
I run SBBS in docker - so it's a foreground process, executed by "sbbs" with no arguments.
But I cant use it, because it detaches from the terminal, which results in the container "dieing". In a container, a process needs to be the contianers "init", and I was using "sbbs" for that. I should be able to work around that, but was thinking it should be fixed on your side :P
I'm not clear what you mean: what should be fixed on my side?
Re: PHP-CGI
By: alter ego to Digital Man on Fri Mar 06 2020 02:34 pm
Re: PHP-CGI
By: Digital Man to alter ego on Thu Mar 05 2020 04:38 pm
I'm not clear what you mean: what should be fixed on my side?
Why when invoking php-cgi (or any cgi), it is rendering more than what cgi is supposed to be rendering?
That, I don't know. It doesn't seem to be happening like that for me. I'll do some more testing and confirm that regular old CGI scripts are working as expected still.
Yeah, that I get, but I do suspect it has something to do with your unique setup.
Re: PHP-CGI
By: Digital Man to alter ego on Thu Mar 05 2020 04:38 pm
I'm not clear what you mean: what should be fixed on my side?
Why when invoking php-cgi (or any cgi), it is rendering more than what cgi is supposed to be rendering?
IE: In the case of php, its rendering the status of the terminal server - and because of this, the browser is treating the output as "text" not "html" (and therefore not rendering it correctly).
Yeah I'm stumped then.
I'm also running this on buster - so I'll check its not buster related as well (I recall previous issues with buster...)
0010: 72 20 32 30 32 30 20 30 39 3a 30 35 3a 35 35 20 r 2020 09:05:5542,46c42,45
<= Recv data, 13 bytes (0xd)
0000: 38 0d 0a 31 32 33 34 35 36 37 38 0d 0a 8..12345678..
== Info: Problem (3) in the Chunked-Encoded data
== Info: Closing connection 0
Re: PHP-CGI
By: alter ego to Digital Man on Fri Mar 06 2020 04:41 pm
Yeah I'm stumped then.
I'm also running this on buster - so I'll check its not buster related as well (I recall previous issues with buster...)
So I'm further stumped by this problem.
I compiled under stretch and didnt have the problem. To be sure, I recompiled the buster container, and no problem. I'm not sure if something was fixed in the last few days?
Anyway, I've noticed another strange problem - when calling curl, I'm getting
curl: (56) Problem (3) in the Chunked-Encoded data
Yet, it seems to render OK in the browser. I did some further debugging, and found if the output was 2 chars or 7 chars in size, there was no chunk encoding error, however, if the output has other sizes there are.
I did a curl trace of a 7 char output (no error) and compared that to an 8 char output - and this is the difference:
[deon@d-1-1 sbbstest]$ diff 7 8
17c17
< 0010: 72 20 32 30 32 30 20 30 39 3a 30 36 3a 30 36 20 r 2020 09:06:06
But I cant use it, because it detaches from the terminal, which results inthe container "dieing". In a container, a process needs to be the contianers "init", and I was using "sbbs" for that. I should be able to work around that, but was thinking it
(Which gives me an idea - I can launch the container without STDIN, I'll tryit.)
Might be easier to use an nginx container setup for PHP, and have aconfiguration to reverse proxy *.ssjs etc to the SBBS web host. I'm
doing that for my configuration right now (not php though), so I can
host a different app and still get through to the synchronet api stuff.
By: Tracker1 to alter ego on Sun Mar 15 2020 11:28 pmOne thing to consider, even if it's mostly idle, when you get hit by say
Might be easier to use an nginx container setup for PHP, and have
a configuration to reverse proxy *.ssjs etc to the SBBS web host.
I'm doing that for my configuration right now (not php though), so
I can host a different app and still get through to the synchronet
api stuff.
Yeah thanks for the idea.
Turned out to be an old bug, which Deuce fixed.
In lieu of php-cgi, I could have run php-fpm (or your nginx idea too)
- but I didnt want to have an mostly idle deamon running. php-cgi
appears to be working now, which is great
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 31 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 89:13:50 |
| Calls: | 2,069 |
| Calls today: | 2 |
| Files: | 11,134 |
| Messages: | 946,774 |