Bug #18716

Acquired lock/Released lock entries in system log

Added by John Angel over 7 years ago. Updated almost 2 years ago.

Status:Resolved Start date:2008-04-28
Priority:Should have Due date:
Assigned To:Michael Stucki % Done:

100%
Category:- Spent time: -
Target version:-
TYPO3 Version:4.2 Is Regression:No
PHP Version:5.2 Sprint Focus:
Complexity:

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)

bug_8274.diff Magnifier (3 kB) Administrator Admin, 2008-04-28 13:56

Related issues

related to Core - Bug #31460: flock() in class.t3lib_div.php Resolved 2011-10-31

History

#1 Updated by Oliver Hader over 7 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)

#2 Updated by Steffen Kamper over 7 years ago

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

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

#3 Updated by Michael Stucki over 7 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.

#4 Updated by Steffen Kamper over 7 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)

#5 Updated by Alexander Opitz almost 2 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.

#6 Updated by Michael Stucki almost 2 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.

Also available in: Atom PDF