Project

General

Profile

Actions

Bug #18716

closed

Acquired lock/Released lock entries in system log

Added by John Angel over 16 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2008-04-28
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.2
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

System log ($TYPO3_CONF_VARS['SYS']['systemLog']) is full of entries like this:

27-04-08 18:34 - typo3: Locking [simple::595aea023905d4fd98f4ec7f73ba9c9c]: Released lock
27-04-08 18:34 - typo3: Locking [simple::6bd9443a0500c007b3ab4d5771d04284]: Acquired lock
27-04-08 18:34 - typo3: Locking [simple::09bfda1c8354fd976a43436366ccc1f3]: Acquired lock
27-04-08 18:34 - typo3: Locking [simple::6bd9443a0500c007b3ab4d5771d04284]: Released lock
27-04-08 18:34 - typo3: Locking [simple::09bfda1c8354fd976a43436366ccc1f3]: Released lock

These lines should be removed:

typo3/sysext/cms/tslib/class.tslib_fe.php:2800

$lockObj->sysLog('Acquired lock');

typo3/sysext/cms/tslib/class.tslib_fe.php::2823

$lockObj->sysLog('Released lock');

(issue imported from #M8274)


Files

bug_8274.diff (3.04 KB) bug_8274.diff Administrator Admin, 2008-04-28 13:56

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #31460: flock() in class.t3lib_div.phpClosedDmitry Dulepov2011-10-31

Actions
Actions #1

Updated by Oliver Hader over 16 years ago

I wouldn't remove these information since they are very useful if something goes wrong and you need to know what. Last week we set up a system with one database but multiple web-hosts behind a load balancer and a database locking.
In this case it was really helpful to know, what was going on.

We have some possibilities to reduce the logged information:
  • setup a $TYPO3_CONF_VARS['FE']['logLockActivity'] which is of type boolean and enables/disables the loggin for locking
  • use the loglevel for t3lib_div::sysLog, which can be set to INFO, NOTICE, WARNING, ERROR or FATAL - like it's done for other servers on e.g. Linux
    > if the level is NOTICE, everything will be logged; if it's ERROR, only errors and fatal erros will be logged
    > $TYPO3_CONF_VARS['SYS']['systemLogLevel'] addresses exactly this scenario (and is already available)
Actions #2

Updated by Steffen Kamper over 16 years ago

yes, $TYPO3_CONF_VARS['SYS']['systemLogLevel'] is the best to do.

Would it make sense to set it by default to 1 ?

Actions #3

Updated by Michael Stucki over 16 years ago

The attached patch adds the "LOG_DEBUG" severity to t3lib_div::sysLog() and changes the default value for the t3lib_lock object.

Please test.

Actions #4

Updated by Steffen Kamper over 16 years ago

two remarks:

we have constants in t3lib_div, it should be added there:
const SYSLOG_SEVERITY_DEBUG = -1;

these should also used in switch ($severity)

Actions #5

Updated by Alexander Opitz about 11 years ago

  • Category deleted (Communication)
  • Status changed from Accepted to Needs Feedback
  • Target version deleted (-1)
  • Is Regression set to No

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?
IMHO this was changed already.

Actions #6

Updated by Michael Stucki about 11 years ago

  • Status changed from Needs Feedback to Resolved
  • % Done changed from 0 to 100

Indeed this has been implemented with #31460 already in 4.5.

Actions #7

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF