Error 500

[theprincy]

i send pm

[gOOvER]

(08-28-2009 07:15 PM)kilburn Wrote:  Could you give me access to this system? Is it a production server?

There are allready Tickets open for this Error. #1955 & #1954

[theprincy]

(08-28-2009 07:51 PM)gOOvER Wrote:  

(08-28-2009 07:15 PM)kilburn Wrote:  Could you give me access to this system? Is it a production server?

There are allready Tickets open for this Error. #1955 & #1954

;(

[theprincy]

ossible to use the panel must continually do over ssh killall -v php5-cgi , and then because of other 3 servers are not experiencing the problem since they are equal?

[kilburn]

Let's continue our discussion in ticket #1954, where I've commited a sort-of-fix for this problem.

[theprincy]

I did just update and it seems that the problem up to now no longer occurs.
I created different domains and emails without a problem, than before it also seems faster.

thanks

[kilburn]

sci2tech Wrote:Gui need to check lock because: 1. not to allow 2 engine instances to be running in same time => corrupted files

I understand that the backend needs locking to prevent multiple instances running at the same time, but as this is already done by the backend itself, why does the gui need to lock too?

sci2tech Wrote:2. second request to engine must wait until first request is finished (otherwise request will not be handled until third request).

This is not an issue, because the second request will fire a new "rqst-mngr" instance, which will sit there blocked (at the flock line, before doing anything) until the first one ends. When the first one has ended, "flock" returns and this second instance will continue as usual.

My only explanation is that gui locking is there to prevent a situation like this happening:

Code:

1. gui creates user "domain1.tld", with it's default mail addresses an such.
2. rqst-mngr (1) is run
3. rqst-mngr (1) launches dmn-mngr, who adds "domain1.tld"
4. gui creates a new user "domain2.tld", with it's default mail addresses and such.
5. rqst-mngr (2) is run, but gets blocked in the "flock" line.
6. rqst-mngr launches mbox-mngr, who tries to add mails for both "domain1.tld" (no problem) _and_ "domain2.tld" (which has not been created yet). Thereafter, bad things _may_ happen.
7. rqst-mngr (1) ends
8. rqst-mngr (2) wakes up
9. rqst-mngr (2) launches dmn-mngr, who adds "domain2.tld"
10. rqst-mngr (2) end

Now, the current code is not preventing this from happenning in some situations (vulnerable to a race condition), and therefore it should be correctly fixed. The key question to answer is: does the above situation really lead to bad things happening?

[sci2tech]

Imagine this:
1. User1 add subdomain -> engine-mgr is running -> ispcp-sub-mng is running and altering /etc/apache2/sites-available/ispcp.conf
2. reseller / admin modify another domain -> ispcp-dmn/sub/als/subals-mngr is running and try to alter same file.
Now if user1 lock engine, second user will not be able to run engine an must wait until a third user trigger engine.
How is supposed to work:
1. User trigger engine
2. Engine create lock.
3. Second user need to trigger engine. Gui check if engine lock exists, If yes, transmit header to prevent browser to drop connection, sleep sleep and retry until engine is unlocked.
Error 500 occur when waiting time >20/30 seconds (depends on configure).
Racing condition occur when 2`nd user trigger engine before 1`st instance create lock.
How can we avoid raceing?
1. Gui test daemon is running (otherwise we can lock the engine permanently). If not trigger error message and stop.
2. Gui test for lock file. If exists, wait, then recheck.
3. Create lock file, then trigger engine.
4. Engine perform request, then remove lock.
Permission will not be a problem as long as engine runs with root privilege.

[kilburn]

That was with old "locking" code. Keep in mind the now we use real locking assets (flock). When flock is called, the function doesn't return until it successfully acquired the lock.

sci2tech Wrote:1. User1 add subdomain -> engine-mgr is running -> ispcp-sub-mng is running and altering /etc/apache2/sites-available/ispcp.conf
2. reseller / admin modify another domain -> ispcp-dmn/sub/als/subals-mngr is running and try to alter same file.
Now if user1 lock engine, second user will not be able to run engine an must wait until a third user trigger engine.

What would now actually happen is:

1. User1 add subdomain -> rqst-mgr is running -> ispcp-sub-mng is running and altering /etc/apache2/sites-available/ispcp.conf
2. reseller / admin modify another domain -> rqst-mngr is run and gets blocked in the "flock()" call until it can acquire the lock.
3. The first rqst-mngr ends, releasing the lock
4. "flock()" call on the second request returns because now it has been able to acquire the lock -> subals-mngr is run and the reseller/admin changes are made effective

See? No gui locking, and still no problem.

[sci2tech]

I did not have time to look at your modifications, but if it work the way you said everything should be ok (and recommended way), and indeed no gui lock is needed. And yes, I was talking about the old way. All we have to do is to drop

PHP Code:

check_for_lock_file();