Bug #15264
closeddatabase connection error warning
Added by Stefano Cecere almost 19 years ago. Updated over 18 years ago.
0%
Description
if mysql is down, i get this error:
"Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (61) in /home/nullone/public_html/typo3_src-3.8.0/t3lib/class.t3lib_db.php on line 831"
and then the TYPO3 nice box saying that there is a connection problem to the database.
could it be possible to not show the PHP warning? it would be much more "professional", and wouldn't show the inner path of my scripts
(issue imported from #M1986)
Updated by Sebastian Kurfuerst almost 19 years ago
Hi,
please try to set a @ in front of the mysql_pconnect call and please check if it works as expected, and then give feedback here.
Thanks and greets, Sebastian
Updated by Martin Kutschker almost 19 years ago
Using the @ will do the trick. Unfortunately you rob yourself of any way to find out what happened.
I'm for using @, but TYPO3 should use some kind of logging to provide details.
Updated by Stefano Cecere almost 19 years ago
uhm.. i think this topic should be discussed in the core dev list, right?
maybe it's something for the DBAL group?
Updated by Sebastian Kurfuerst almost 19 years ago
Hi Stefano, that the discussion takes place here is perfectly fine!
Greets, Sebastian
Updated by Sebastian Kurfuerst almost 19 years ago
Hi Karsten,
it would be good if you could give your comments here.
Greets, Sebastian
Updated by Karsten Dambekalns almost 19 years ago
Well, supressing the error with works, but is a bad solution. Using the
should be reserved for the very rare occasions where errors are actually expected but should be handled gracefully.
If your PHP displays errors to the frontend, this should rather be fixed on system level by having PHP log error output to a file instead of displaying it to the browser (every good hosting environment should do this anyway). This way the error stays "visible", with @ it just "disappears".
What TYPO3 could do (generally) is to try to set this setting with ini_set. I'll have a look.
Updated by Martin Kutschker almost 19 years ago
Karsten, you're repeating pretty much what I wrote.
I sugest something hookable like typo3_div::devLog. So you can log into a file, using syslog, etc. Using syslog especially is fine as syslog has the feature to log on other machines.
Updated by Karsten Dambekalns almost 19 years ago
Setting display_errors to 0 in index_ts.php and init.php supresses the errors for FE and BE. But this kind of defeats the lines in those files setting error_reporting to "E_ALL ^ E_NOTICE". This should be configurable, I think, maybe coupled to debug mode in TYPO3? Opinions?
Updated by Stefano Cecere almost 19 years ago
maybe it could be nice to log all errors in the already implemented log module of the BE?
with a new category name: errors?
Updated by Martin Kutschker almost 19 years ago
Karsten, PHP error display is already coupled to the "debug hosts" (list of IP addresses which get debug notices). If not in 3.8 then in CVS.
Stefano, using the BE log is not be possible as a DB error prohibits logging in the BE. For this we need a more reliable mechanism. I'm thinking of a text file, which relies only in write permssions and disk space:
function t3lib_div::sysLog($msg, $extKey, $severity=0) {
global $TYPO3_CONF_VARS;
if ($TYPO3_CONF_VARS['SYS']['logFile']) {
$file = fopen($TYPO3_CONF_VARS['SYS']['logFile'],'a+');
if (!$file) {
die('Cannot open TYPO3 system log: '.$msg);
}
if (!fwrite($file,date('d/m/Y i:H').' - '.$severity.' - '.$msg.char(10))) {
die('Cannot write to TYPO3 system log: '.$msg);
}
fclose($file);
}
if (is_array($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_div.php']['sysLog'])) {
$params = array('msg'=>$msg, 'extKey'=>$extKey, 'severity'=>$severity);
$fakeThis = FALSE;
foreach($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_div.php']['sysLog'] as $hookMethod) {
t3lib_div::callUserFunction($hookMethod,$params,$fakeThis);
}
}
}
Severity: 0 is info, 1 is notice, 2 is warning, 3 is error, 5 is immediate action required
Updated by Stefano Cecere almost 19 years ago
seems perfect!
later a BE module to read this file could be developed.
Updated by Karsten Dambekalns almost 19 years ago
Martin, you are right. In CVS error display is coupled to devIPmask and/or displayErrors, 3.8.0 already allowed to set displayErrors (without paying attention to devIPmask) - so overall this bug is resolved.
As for the logging to a file: this is IMHO a different story. It should be possible to do such logging, but PHP error messages cannot be logged with a user function AFAIK. The question in this case is, does it make sense to try to ini_set 'error_log' to a specified file?
Updated by Martin Kutschker almost 19 years ago
The idea was that mysl_pconnect is used with an @ BUT WITH PROPER error handling. TYPO3 has a bad habit of not checking the results of system calls. The correct way is (IMHO):
function sql_pconnect($TYPO3_db_host, $TYPO3_db_username, $TYPO3_db_password) {
if ($GLOBALS['TYPO3_CONF_VARS']['SYS']['no_pconnect']) {
$this->link = @mysql_connect($TYPO3_db_host, $TYPO3_db_username, $TYPO3_db_password);
} else {
$this->link = @mysql_pconnect($TYPO3_db_host, $TYPO3_db_username, $TYPO3_db_password);
}
if (!$this->link) {
t3lib_div::sysLog('Could not connect to Mysql server: ' . mysql_error(),'',5);
}
return $this->link;
}
As for using a log for all PHP errors. Could be an optional feature, but I prefer real checks by the application.