statusnet 0.9.7 and log level

jbfavre

Hello,
Yet another question with my own statusnet instance. When activating logs, I got a lots of DEBUG logs:
grep LOG_DEBUG ../logs/statusnet.log |wc -l
2006

Problem is that default configuration disable debug log:
grep logdebug lib/default.php
'logdebug' => false,

My own configuration also disable it:
grep logdebug /etc/statusnet/statusnet.php
$config['site']['logdebug'] = false;

So, it seems that this config directive is not taken into account. How can I get logs without debug's ones ?

Regards

jordanc

@jbfavre I believe that logdebug is just for the pearDB errors. By default without changing anything statusnet logs to syslog.

jbfavre

@jordanc Thanks for the tips. Now, is there a way to get less detailled logs ? I don't need debug logs all the time.

jordanc

@jbfavre If the config setting isn't sticking, you can try using the setconfig.php script from the command line
php setconfig.php site logdebug false

jbfavre

@jordanc OK, tried. But I missed a point: DEBUG logs seems to only occurs from queuedaemon. Is he not supposed to pick out configuration ?

2011-03-25 13:28:19 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] DBQueueManager (main): Checking for notices...
2011-03-25 13:28:19 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] DBQueueManager (main): No notices waiting; idling.
2011-03-25 13:28:19 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] Waiting up to 10 seconds for socket data...
2011-03-25 13:28:29 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] DBQueueManager (main): Checking for notices...
2011-03-25 13:28:29 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] DBQueueManager (main): No notices waiting; idling.
2011-03-25 13:28:29 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] Waiting up to 10 seconds for socket data...
2011-03-25 13:28:39 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] DBQueueManager (main): Checking for notices...
2011-03-25 13:28:39 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] DBQueueManager (main): No notices waiting; idling.
2011-03-25 13:28:39 LOG_DEBUG: [status.jbfavre.org:queuedaemon.php:41999] Waiting up to 10 seconds for socket data...

jordanc

@jbfavre I'm not too familiar with how the logging works with regards to the queuedaemon, I'll try to check it out with the devs and get back to you later.

jbfavre

Hi @jordanc, any new about this topic ?
Regards,
JB

jbfavre

@jordanc, any new about this topic ?

jordanc

Whoops. Not yet, sorry.

jbfavre

no problem.
Just that it was a nightmare to diagnose this week-end issue with queue manager: either too few logs, or too much.
In this case, too few: I disabled logs because could not disable DEBUG :(

jordanc

In the meantime you could just pipe them through | grep -v LOG_DEBUG and it wouldn't show you any lines with that

jbfavre

@jordanc yes, that's what I did to forensic the issue ;)
But doing that increases disk I/O (for limited time though)
And that won't prevent logfile growth: around 600MB for 2 days :(

jbfavre

@jordanc, up again, any news ? ;)

jordanc

@jbfavre You may need to restart the queues for them to pick up the appropriate log level settings.

jbfavre

@jordanc well... how to say that... since I have some issues with queuemanager (see http://status.net/open-source/issues/3165), indeed I already restarted the queues many times.

I can confirm that log level is NOT currently taken into account.

Maybe I need to tune php.ini for cli or something else, but I did not found any informations about that.

jkltechinc

I'm having the same problems. I noticed that none of my daemons, including the facebook and twitter bridge (just for posting, logging in with oauth still worked) and my xmpp daemon just refused to run. The startdaemon.sh script exited with no result and getvaliddaemons.php returned something like "File too large. Exiting."

Got everything working again when I deleted the log file, but it quickly filled up to 3k lines in just minutes. I thought about adding a logrotate entry, but decided just to try disabling debug in the config.php. No such luck, so I disabled logging all together.

I tried several combinations of restarting the daemon after adding the line that's supposed to disable the debug log level with no such luck.

jordanc

It may be that the config.php settings are not getting recognized for some reason, try running
php /snbase/scripts/setconfig.php -a |grep log
That will show you all related log settings from the DB, it will probably look something like this (with some logo stuff etc)
site logfile NULL
site logdebug false
site logperf false
site logperf_detail false

You can then change those with
php /snbase/scripts/setconfig.php column1 column2 value

jbfavre

@jordanc
Have executed the command. Seems that syslog is setup somewhere.
But I did not defined it in config file (or maybe earlier but not now).
Have added $config['syslog']['priority']='info' into config file.
Will see what happen.

Here're the detailled results:
$ php scripts/setconfig.php -a | grep log
site logfile '/path_to_log_file/logs/statusnet.log'
site logdebug 'false'
site logperf false
site logperf_detail false
db log_queries false
db log_slow_queries 0
syslog appname 'statusnet'
syslog priority 'debug'
syslog facility 8

And from DB:
mysql> select * from config where setting like "%log%";
+---------+----------+------------------------------------+
| section | setting | value |
+---------+----------+------------------------------------+
| site | logdebug | false |
+---------+----------+------------------------------------+

jbfavre

Just a quick update to tell that my differents tries did not changed anything.
I still have many DEBUG logs even if I disabled them.

Seems that these logs are done with function common_log from /lib/util.php
But I can't figure out how and where config is parsed.

Any idea ?

etique57

Just to up this... Same problem, millions of log entries because of the daemons with the latest stable (1.0.1).

Log file reach GB size after a few weeks.

gabev

Same problem here ... 1.0.1 .
i tried to use jordanc solution: php setconfig.php site logdebug false ..didnt work.
restarted the daemons ...still the same problem ..debug logs contiue to fill up.

From the timeline of the answers i can see that the dev team doesn't really care about..the issue was raised long ago and no def answer to solve it.
Also documentation is very poor and spread all over and it's really hard to fix those issues especially when we dont have any feedback or guidance from the dev team or when our questions don't get answered for months ..

Is anyone there which actually fixed that issue ?

terminus

A workaround is to comment out the lines that write the log entries you don't want. For me, the worst ones to comment out are in lib/dbqueuemanager.php and lib/iomaster.php. Just put // in front of the lines that write to the log.