PHP stderr lost

[bogus]

Hello,

I don't kwon whether it is a PHP or LSWS bug.

When I restart LSWS, it reuses the previous PHP Fast-CGI process, but then, stderr is lost, as If PHP did not use the FastCGI connection to write its standard error, but still the standard error output (catchable by lsws only if it is its original parent).

That's very annoying, because I must kill PHP each time I restart LSWS.

 

[mistwang]

Thank you for the bug report.

PHP fast CGI does not strickly follow fast CGI specification, it still writes standard error to the original stderr (file handle 3).

PHP's stderr is assigned to a anonymous pipe when it was started by LSWS, LSWS log every thing received from the pipe to the stderr log. So when LSWS restarts, new LSWS instance can not pick up the old pipe connection thus can not log output of stderr any more.

We are thinking about always restarting another set of PHP processes instead of reuse the old one when LSWS restarts. But the difficult part is when/how to stop those old PHP processes.

 

[xing]

How about this.

1) When LSWS restarts, it spawns new php fastcgi group. Lsws would know at least the starting processid number of the new group.
2) Loop through current running processes and find all php processes with id lower than this number and send kill signal to them?

There is a loop-hole with this since lsws can kill long-running non-fastcgi spawned php proccesses such as scheduled cron jobs.

 

[mistwang]

Thank you for the suggestion.

Right now LSWS does graceful restart, means that the old LSWS instance still need the old PHP processes before it finishs all pending requests. Let new LSWS instance to manage old PHP processes may break the graceful restart.

I am thinking to have the watch dog process of old LSWS instance to manage old PHP processes as it knows when the old LSWS process exits, even crashes. Only need to find the best way to inform watch dog process about PIDs of children processes started by LSWS worker process.

 

[bogus]

PHP fast CGI does not strickly follow fast CGI specification, it still writes standard error to the original stderr (file handle 3).

So, that is definitly not a LSWS bug, but rather a PHP one. I'm going to report there. Thanks for the replies.