[TYPO3-core] RFC: error logging for the Core

[Martin Kutschker]

Michael Stucki <michael at typo3.org> writes on 
Fri, 06 Jan 2006 13:02:41 +0100 (MET):

> 
> > The default operation is configurable (and has to be turned on
> > manually),
> > so you can use the default and any custim logging.
> 
> Sorry, but double logging does not make sense.
> If you don't do both at once, an extension could use the
> TYPO3_CONF_VARS setting too.


I don't think so, but here you are. Any custom logging turns of default logging.

Note: you can have more than one custom logging, so your point is not really valid. And - on your request - you can use all of the default loggings at the same time.


> I think you could easily provide all options. After all it's not much
> more code.


Here you are.


> >> Either way, it would be nice to have this, but it will only be
> > > really
> >> useful, if it widely deployed throughout the core (and
> > > extensions).
> > 
> > I see. For normal cases they could use the devLog. So perhaps the
> > new should be constrained to (fatal) errors.
> 
> As the name already says, devLog is useful for developers. That's a
> different topic.
> 
> 
> > * rename it from sysLog() to errLog()
> 
> Still prefer sysLog because it doesn't neccessarily need to be errors
> that will be logged. Examples:


Reverted it back to sysLog().


> I still like it but suggest that you use the same severities like
> syslog()
> does: http://ch.php.net/syslog


Neither DEBUG nor the extremely fine grained serious error section akes much sense. So only INFO up to CRIT are supported.


> An additional "level" configuration option would be useful to log
> login/logout information of the be_users, etc.


Done. There is one general logging level and you can override it for each logging type. This makes sense if you want only mails in emergency situations.


> Can you repost it as unified diff, please?


Nah, it's readable as it is and here comes a new one.

The new options are:

$TYPO3_CONF_VARS['SYS']['systemLog'] = <option>[;<option>,...]
option = <type>[,<destination>[,<level>]
type = <string>
destination = <string>[/<string>]
level = <int>

file,/path/to/log/file,2
mail,user at domain.tld
mail,to at domain.tld/from at domain.tld
syslog,local1
error_log,,3

I have removed the support for the different types of error_log as they can be be configured directly with "file" and "mail".


> > The syslog options needs a openlog() which I have ommited in this
> > patch.
> > It should be opened early in the code (both BE and FE).


This code includes the init function but not the actual call.


> > Normally it should use this ident:
> > t3lib_div::getIndpEnv('TYPO3_REQUEST_HOST')
> > 
> > What to use in CLI mode? The TYPO3 path?
> 
> I think PATH_site should be fine for all situations.


Don't think so. Depending on your lof setup (remote logging!) you may need the host name. It's now

Web: <protocol>://<request-hostame>
CLI: <fqdn-hostname>:<TYPO3-path>


> > if ($TYPO3_CONF_VARS['SYS']['errorLog'] === 'syslog') {
> > define_syslog_variables();
> > openlog($ident,LOG_ODELAY,LOG_USER);
> > }
> 
> LOG_* should be configurable, see above. See syslog() for a list of
> valid facilities.


Done.

Masi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-diff
Size: 4751 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060106/e5054916/attachment.bin