Bug #6044
closed
production.log should have timestamps in it
Added by Bryan Kearney almost 10 years ago.
Updated almost 6 years ago.
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1101093
Description of problem:
production.log should have timestamps in it for easier investigation of issues
Version-Release number of selected component (if applicable):
Satellite-6.0.3-RHEL-6-20140521.0
How reproducible:
always
Steps to Reproduce:
1. Check /var/log/foreman/production.log
Actual results:
Records in the log do not have timestamps in it
Expected results:
Records in the log should have timestamps in it
Additional info:
Bug 790966 was similar but for /var/log/katello/production.log
- Category set to Rails
- Status changed from New to Need more information
- Assignee deleted (
Ivan Necas)
I can't replicate this on a Foreman installation, would be good to narrow down if it's with Katello.
# tail -20 /var/log/foreman/production.log
Started GET "/" for 127.0.0.1 at 2014-06-04 12:12:04 +0100
Processing by DashboardController#index as */*
Redirected to https://0.0.0.0/
Filter chain halted as :require_ssl rendered or redirected
Completed 302 Found in 8ms (ActiveRecord: 0.0ms)
Started GET "/" for 127.0.0.1 at 2014-06-04 12:12:21 +0100
Processing by DashboardController#index as */*
Redirected to https://0.0.0.0/users/login
Filter chain halted as :require_login rendered or redirected
Completed 302 Found in 81ms (ActiveRecord: 5.6ms)
Started GET "/users/login" for 127.0.0.1 at 2014-06-04 12:12:25 +0100
Processing by UsersController#login as */*
Rendered users/login.html.erb within layouts/login (67.6ms)
Rendered layouts/base.html.erb (1.7ms)
Completed 200 OK in 150ms (Views: 146.4ms | ActiveRecord: 0.3ms)
- Status changed from Need more information to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2200 added
Dominic, the issue was that not every line has it's own timestamp. The log becomes hard to understand when there are more workers writing logs at the same time, so timestamp (or ideally some UUID of thread) would help.
Marek Hulán wrote:
Dominic, the issue was that not every line has it's own timestamp. The log becomes hard to understand when there are more workers writing logs at the same time, so timestamp (or ideally some UUID of thread) would help.
Yes indeed, that's definitely an issue, though not the one that's described :)
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
- translation missing: en.field_release set to 28
- Related to Bug #9606: The debug level logging adds many ESC charactors in the production.log file added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Anonymous