Bugzilla – Bug 442
timestamps for events in slimserver.log would be useful
Last modified: 2011-03-16 04:19:51 UTC
Items entered into /tmp/slimserver.log have no timestamp. This makes it hard to tell whether entries in there are related to a problem you have recently observed or not.
Logging done explicitly by SlimServer does include timestamps, but system and Perl generated errors do not. Can you attach a sample log file so I can make sure that the errors that you are seeing get logged properly?
Created attachment 67 [details] Example log with no timestamp information
that's a log of CPAN stdout information. slimserver has no control over that.
Maybe the answer then is to output a timestamp to the log file periodically - say once a day. That way at least you can tell whether the errors are recent or not.
that's an interesting idea. one potential issue woudl be that I can see some users might be put off by having data being written to the log when there is nothing to log. Any thoughts on that? once a day might be a good compromise, that's true, but it is not inconsequential to set up a 24 hour timer. All timers are checked once per second, so there is a fractional amount of overhead to consider. what do you think dean?
Yes, I think we shouldn't log unless there's a specific issue we are logging. Unless there's a way to intercept STDERR and STDOUT and add timestamps, I'm not sure there's anything we can do.
I'm not a perl expert, but I just saw something that looks like it might be related to this issue in the exim mailing list: -- I've cracked a problem causing disconnections by clients. Output from perl's "warn" statement is written to the client interface by default. Library routines (Mail::SRS for example) are unaware of this and the client disconnects having been fed garbage. Ths solution is to use this little bit of perly magic: $SIG{__WARN__} = sub { Exim::log_write($_[0]) }; Output then goes to the logfile. -- Could this be used to route warning messages from other Perl modules to a method that timestamps the output and sends it to the log file?
Thanks Marc, seems to work. Commited in revision 3927. Please verify.
I'm still running 5.4.1, so you might want to re-assign this to someone in your qa group for verification if you want it to be at all timely...
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.