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

[Michael Stucki]

Hi Martin,

>> On Wednesday 04 January 2006 23:58, Michael Stucki wrote:
> 
> Odd. Either I didn't get Michael's mail or I deleted it accidentally.

I just posted it again. Hope you get it this time.

>> > instead! Bad that you perform the default log operation before
>> > checking for the hook (IMHO it should simply replace the built-in
>> > functionality).
>> 
>> +1
> 
> 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 prefer these solutions in the following order:
> 
> There is little consenus here :-(
> 
> Anyway, my patch had no default order at all. The if/ifelse part only
> evaluated the config option.

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

>> > 1. Write the file manually:
>> > Works everywhere just out-of-the box.
> 
> Is the same as error_log with type=4, but has the drawback that we have to
> rely on advisory file locking.
> 
> I should have never brought this up.

config.stat_apache_log doesn't work much different. I think we should just
use the same function here.

>> > 2. Call syslog()
>> > I can setup syslog to log TYPO3 messages into a separate logfile
>> > - no
>> > TYPO3 involved, only the facility that needs to be configured
>> > through TYPO3_CONF_VARS.
> 
> You can configure PHP to use syslog with error_log, but it could be an
> extra option.

It should be a separate option.

>> > 3. Use error_log()
>> > In my opinion, error_log() is probably useful for short time
>> > debugging, but it is not helpful to be used as a permanent system
>> > log because of endless-repeating syntax error reports.
> 
> error_log has 3 methods of logging, but well.

I want to separate the PHP problems (parse errors, etc.) from TYPO3 which is
a totally different application! Still don't like that option...

>> 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:

- Could not connect to database (error)
- be_user admin/password is still active (information)
- deprecated function in use (information)

> * remove the severity argument

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

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

> The attached patch implements this.

Can you repost it as unified diff, please?

> The log is configured via $TYPO3_CONF_VARS['SYS']['errorLog']
> 
> The manifold options for anyones preferences are:

Can one use many of them at the same time?

> file:/path/to/log/file
> mail:user at domain.tld
> syslog
> error_log:system
> error_log:user at domain.tld
> error_log:/path/to/log/file

syslog needs to know a facility. I think we should the users decide which
facility they want, but use "USER" by default.

> 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).
> 
> 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.

> 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.

Regards, michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/