Support

mistwang · #11 08-03-2006, 11:08 AM

Admin interface use the pre-built PHP binary, so it has the timeout problem.

Not sure about the graceful restart problem though, may be some thing wrong with Solairs 10, does it work without chroot? Is your server 64-bit or 32-bit?

sofatime · #12 08-06-2006, 12:13 PM

The server is 64-bit (Opteron).

I have tested with and without chroot: It seems it has nothing to do with chroot, as this happens without chroot too. But it looks like it has to do with the normal lsphp processes. This is what I did:
- started lsws
- opened admin, changed some setting, restarted using the admin
- restart worked and I could use the admin (even without timeouts), could change another setting, restart again, no problem
... until I opened a php-page of a normal site. From that moment the admin does not respond anymore (until restarted using lswsctrl).

If I do the same as above, but I stop/start the server after config changes using lswsctrl everything works normally.

Does that make sense?

About the fact that stopping takes a long time using lswsctrl: That only happens when normal lsphp processes are running. If I stop the server right after starting (when no lsphp processes are running yet) it stops immediately.

Apart from that the server works normally, also php.

mistwang · #13 08-06-2006, 06:11 PM

That pretty strange.
Do you mean that admin stop working completely once a php page of a normal site was accessed? Not even able to load any admin page? Is there any "admin_php" process running?
You can try to replace "lsws/admin/fcgi-bin/admin_php" with your customized lsphp binary, but I am not sure the admin console will work cleanly under PHP5 or not. You can give it a try. :-)

Have you tried "lswsctrl restart"? Does that work when admin console failed?

sofatime · #14 08-08-2006, 01:58 AM

Yes, admin stops working completely, and yes, there is a admin_php process running. But it does not happen every time. Sometimes I can do several changes/restarts without problems.
I replaced admin_php with my own php. Didn't change. Some config changes/restarts were ok, then it blocked again.

I can not really say anything about "lswsctrl restart". I tried it a few times and it worked but I remember that it did not work in the past. Only complete stop and start works every time.

How is the restart using admin_php done? As there is no kill command in the chroot I assume some other way?

BTW: I didn't notice any problems with the admin interface using php 5.1.4.

Any other idea? If not - no big deal. I can live with that for now, there shouldn't be too many config changes.

sofatime · #15 08-08-2006, 02:05 AM

Sorry, I misunderstood your question about "lswsctrl restart". When the admin console failed and I do "lswsctrl restart" it works again (until I load a normal php page).

mistwang · #16 08-08-2006, 07:13 AM

Which version of solaris 10 are you using?

Quote:

How is the restart using admin_php done? As there is no kill command in the chroot I assume some other way?

The admin interface made a connection back to web server and tell it to restart. Do not use kill.

If you don't mind, can you please post the the trace result of "ktrace" of the admin_php when it stop working?
Also, debug logging can be turned on for the admin interface by changing log level to "debug" for the admin vhost, and "debug level" to "HIGH" at server level. If you server is in production yet.

Thanks.

sofatime · #17 08-08-2006, 09:12 AM

Its Solaris 10 3/05.

About ktrace: Unfortunately I do not know this tool. Some research showed me this is called truss on Solaris. I will try this tomorrow, and also the debug log for the admin vhost. Maybe you can give me instructions on how to use truss?

mistwang · #18 08-08-2006, 09:31 AM

Quote:

About ktrace: Unfortunately I do not know this tool. Some research showed me this is called truss on Solaris. I will try this tomorrow, and also the debug log for the admin vhost. Maybe you can give me instructions on how to use truss?

Sorry about that, ktrace probably is a BSD thing. Usually, you can use "truss -d <pid>" to attach to a running process to trace system calls made by that process.
This way, you can get a rough idea about what a process was doing.

sofatime · #19 08-09-2006, 01:46 AM

I did the following:
- debug level to high at server level
- log level to debug at vhost admin level
- truss -p PID

Then I changed a setting in lsws admin, did graceful restart, opened a normal PHP page, then admin blocked (browser waiting for answer).

truss-output:
read(0, 0x0827A670, 8192) (sleeping...)
read(0, 0x0827A670, 8192) = 0
close(0) = 0
_exit(0)
The first line immediately, the last three lines after a few minutes. Then admin_php was gone! Until now I didn't wait so long, so I didn't notice that admin_php stops. And it does not get restarted again.
The truss-thing was a bit difficult, because apparently admin_php gets stopped when I do a graceful restart and a new process gets started, so I had to do a new truss with the new PID.

error_log:
There is no entry concerning the request which does not get answered. The last entry is:
2006-08-09 10:24:59.206 [DEBUG] [192.168.x.x:3075-1] Keep-alive timeout, close!
2006-08-09 10:24:59.206 [DEBUG] [192.168.x.x:3075-1] Close socket ...
But that was from the last request before restart (I think).

I also did netstat -a which shows an established connection to 7080.

I also want to stress again, that this does not happen every time. It's about every 5th time, and I don't know when it happens and when it works.

mistwang · #20 08-09-2006, 06:15 AM

Looks like something wrong with the event dispatcher, the server does not get the event from OS regarding the blocked request at all.

Are you using devpoll(), if so, please give plain poll() a try, see if it help.

Thank you very much for the debug information. :-)