+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Support Area (/forum-30.html)
+--- Forum: Usage (/forum-34.html)
+--- Thread: Daemon trouble (/thread-7775.html)
Pages: 1 2
RE: Ispcp v1.0.3 testers needed - Nuxwin - 09-06-2009 08:04 AM
In my opinion it is not a problem of execution of the daemon script backend. It is simply EOL (LF -> line feed) missing from the templates parts.
I already corrected several files. Thank you to install the latest revision r1975 and inform us if the problem persists.
What is your distro?
RE: Ispcp v1.0.3 testers needed - theprincy - 09-06-2009 08:14 AM
(09-06-2009 08:04 AM)nuxwin Wrote: In my opinion it is not a problem of execution of the daemon script backend. It is simply EOL (LF -> line feed) missing from the templates parts.
I already corrected several files. Thank you to install the latest revision r1975 and inform us if the problem persists.
What is your distro?
debian lenny
RE: Daemon trouble - sci2tech - 09-06-2009 09:10 AM
This has nothing to do with EOL chars. If you want to reproduce, just overwrite ispcp_daemon while is running. Lack of EOL will affect only engine, not daemon, and will be reflected by changing status like "get tag() ...".
To undestand witch are the steps:
GUI need to run engine and call function send_reguest;
Send_requast open a socket to port where daemon is listening and send a string.
Daemon answer with status
GUI send command to run engine
Daemon run ispcp_rqst_mngr
ispcp_rqst_mngr check against database if there is some component that require modification (check field status in table)
If yes it runs (as external app) ispcp_xxx_mngr where xxx can be als, dmn etc.
If ispcp_xxx_mngr need a template that lack proper EOL then it will fail to find end tag and status will be changed to reflect that. But there will not be any catastrophic failure to prevent future engine runs, also daemon to hang or return 0 status. So please live this closed because has nothing to do with improper template file.
RE: Daemon trouble - Nuxwin - 09-06-2009 09:38 AM
(09-06-2009 09:10 AM)sci2tech Wrote: Lack of EOL will affect only engine, not daemon, and will be reflected by changing status like "get tag() ...".
Yes, I know already.
(09-06-2009 09:10 AM)sci2tech Wrote: To undestand witch are the steps:
GUI need to run engine and call function send_reguest;
Send_requast open a socket to port where daemon is listening and send a string.
Daemon answer with status
GUI send command to run engine
Daemon run ispcp_rqst_mngr
ispcp_rqst_mngr check against database if there is some component that require modification (check field status in table)
If yes it runs (as external app) ispcp_xxx_mngr where xxx can be als, dmn etc.
If ispcp_xxx_mngr need a template that lack proper EOL then it will fail to find end tag and status will be changed to reflect that.
You're not telling me anything there ...
(09-06-2009 09:10 AM)sci2tech Wrote: But there will not be any catastrophic failure to prevent future engine runs, also daemon to hang or return 0 status. So please live this closed because has nothing to do with improper template file.
For me, when a status 0 is returned, this indicates that the daemon is stopped. A code 250 indicates that the request (at the daemon level) it's Ok
But then, what exactly is the problem? I made test.
RE: Daemon trouble - kilburn - 09-06-2009 11:13 AM
Just for the record:
Quote:root 29829 0.0 0.0 3496 736 pts/0 S+ 21:17 0:00 grep ispcp_daemon
root@london:~# kill -9 29831
-bash: kill: (29831) - No such process
root@london:~# kill -9 3496
-bash: kill: (3496) - No such process
root@london:~# kill -9 720
-bash: kill: (720) - No such process
root@london:~# kill -9 ispcp_daemon
-bash: kill: ispcp_daemon: arguments must be process or job IDs
You didn't had the daemon running. The process shown here is the "grep" process itself (that had obviously already finished when you did try to kill it), because you did get this output in return of a 'ps -fe | grep ispcp_daemon' or something similar
RE: Daemon trouble - Nuxwin - 09-06-2009 01:46 PM
@sci2tech
After several tests on Debian lenny with the latest revision r1975, I cry out loud that there is no problem in terms of creating user accounts.
For cons, the deletion of user accounts is a problem and I think it can influence the rest. See this ticket for more information on this subject: http://www.isp-control.net/ispcp/ticket/1976
I'll fix that ASAP...
Note : The same bug exist with OpenSuSE.
Edit:
Ok, I found the source of the bug. I'll make a report because it is a package of peanuts...
RE: Daemon trouble - Nuxwin - 09-06-2009 05:04 PM
Ok, I think I found the source of the bug attached to http://www.isp-control.net/ispcp/ticket/1976
When you delete a domain account, many managers are executed one after the other. The execution order of these managers is established by the dispatcher ( ispcp-rqst-mngr ). The problem, as explained in my ticket, is that the records concerning the htusers and htgroup data are not removed and remains in a status 'delete'. This is explained by the fact that when the managers of these data is performed, the data of domain to which they are linked have been already deleted in the database.
Example for deleting a record in the table htaccess_users:
The subroutines htusers_mngr_engine() of ispcp-htusers-mngr script executes the following query:
Code:
my $sql = "
SELECT
`t1`.`uname`, `t1`.`upass`, `t1`.`dmn_id`, `t1`.`status`, `t1`.`id`, `t2`.`domain_name`
FROM
`htaccess_users` as `t1`, `domain` as `t2`
WHERE
`t1`.`id` = '".$main::htusers_task_id."'
AND
`t1`.`status` != 'ok'
AND
`t1`.`dmn_id` = `t2`.`domain_id`
";The purpose of this request is to select records in the htaccess_users and domain tables. In PSEUDO CODE (made in Laurent), this gives:
Code:
SELECT
SEVERAL DATA FROM HTACCESS_USERS AND DOMAIN
WHERE
HTACCESS_USERS_ID EQUAL HTUSERS_TASK_ID
AND
HTACCESS_USERS_STATUS NOT_EQUAL OK
AND
HTACCESS_USERS_DMN_ID EQUAL DOMAIN_DOMAIN_IDThe problem here is that DOMAIN_DOMAIN_ID match HTACCESS_USERS_DMN_ID has already been deleted from the domain table when the query is executed. Indeed, if this query works for queries like "toadd" or "change", it can not find results for queries like "delete".
Indeed, the dispatcher ( ispcp-rqst-mngr ), place the running of managers in charge of processing htusers and htgroup data after the manager who manages the data related to the domain. Thus the sql query attached below, in the case of a query 'delete', will always return empty result because when it is executed, the domain record DOMAIN_DOMAIN_ID has already been deleted. Uh, I repeat myself here ...
In short, I do not know if you understand me but hey, I did do my best. I suppose this problem is valid for alias domains and subdomains ( todo check
).This is a heresy as fact, as it stands, all the routines for deleting htusers and htgroup data are used strictly for nothing. It is also noted here that the existence of XXX delete operations on the FilesSystem concerning htusers and htgroup did not arise since the file /var/www/virtual/{DOMAIN} has already been deleted .
Besides, my ispcp-htusers-mngr.stdout file proves that I am right:
Code:
DEBUG: push_el() sub_name: htusers_mngr_start_up(), msg: Starting...
DEBUG: push_el() sub_name: check_master(), msg: Starting...
DEBUG: push_el() sub_name: sys_command(), msg: Starting...
DEBUG: push_el() sub_name: sys_command('export COLUMNS=120;/bin/ps auxww | awk '$0 ~ /ispcp-rqst-mngr/ && $0 !~ /awk/ { print $2 ;}' 1>/tmp/ispcp-cc.stdout 2>/tmp/ispcp-cc.stderr'), msg: Ending...
DEBUG: push_el() sub_name: del_file(), msg: Starting...
DEBUG: push_el() sub_name: del_file(), msg: Ending...
DEBUG: push_el() sub_name: del_file(), msg: Starting...
DEBUG: push_el() sub_name: del_file(), msg: Ending...
DEBUG: push_el() sub_name: check_master(), msg: Ending...
DEBUG: push_el() sub_name: get_conf(), msg: Starting...
DEBUG: push_el() sub_name: get_file(), msg: Starting...
DEBUG: push_el() sub_name: get_file(), msg: Ending...
DEBUG: push_el() sub_name: setup_main_vars(), msg: Starting...
DEBUG: push_el() sub_name: decrypt_db_password(), msg: Starting...
DEBUG: push_el() sub_name: decrypt_db_password(), msg: Ending...
DEBUG: push_el() sub_name: setup_main_vars(), msg: Ending...
DEBUG: push_el() sub_name: get_conf(), msg: Ending...
DEBUG: push_el() sub_name: doSQL(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Ending...
DEBUG: push_el() sub_name: htusers_mngr_start_up(), msg: Ending...
DEBUG: push_el() sub_name: htusers_mngr_engine(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Ending...
DEBUG: push_el() sub_name: htusers_mngr_engine(), msg: Ending...
DEBUG: push_el() sub_name: htusers_mngr_shut_down(), msg: Starting...
DEBUG: push_el() sub_name: htusers_mngr_shut_down(), msg: Ending...As one can easily see, after the SQL query, no treatment is performed. This is normal since the query can not find record.
The direct consequence of this bug and the debugger (via frontend) indicate that it still remains to perform queries, and it is surely because of this bug full user continue to report this behavior.
Something crazy huh. Go, bring me the guilty that I can blame publicly.
FIXED in r1977
RE: Daemon trouble - sci2tech - 09-06-2009 06:21 PM
Well, it is a bug but has nothing to do with daemon
. Different story -> please use different thread
RE: Daemon trouble - Nuxwin - 09-06-2009 06:33 PM
(09-06-2009 06:21 PM)sci2tech Wrote: Well, it is a bug but has nothing to do with daemon
Sorry sir I'm an idiot
... In addition, the bug of which you speak do not have one as I told you via PM. It's more like a segfault. If users do well to keep doing is updating correctly ... --> Stopping the daemon (/etc/init.d/ispcp_daemon stop) before overwrite it Beware, I bite