datefmt for not precise enough

Bug #727377 reported by Daniel Brownridge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VMBuilder
New
Undecided
Unassigned

Bug Description

When calling the vmbuilder script from the command line the date format of the timestamps in the log entries is good. e.g.
2011-03-01 21:11:43,057 INFO : Calling hook: post_install
2011-03-01 21:11:43,065 INFO : Calling hook: preflight_check
2011-03-01 21:11:43,110 INFO : Calling hook: configure_networking
2011-03-01 21:11:43,121 INFO : Calling hook: configure_mounting
2011-03-01 21:11:43,130 INFO : Calling hook: mount_partitions
...

But the log file produced in the /tmp directory for some reason has a much less specific date format e.g.

2011-03-01 19:50 DEBUG : Loading plugins
2011-03-01 19:50 DEBUG : ['dpkg', '--print-architecture']
2011-03-01 19:50 DEBUG : amd64"
2011-03-01 19:50 DEBUG : Returning value None for configuration key ppa

As can be seen by only being able to see to the nearest minute when an entry occurred it is not very useful for later analysis of the file.

The problem arises from a 'datefmt' parameter being specified in the call to logging.basicConfig in /usr/lib/python2.6/dist-packages/VMBuilder/log.py

As described hear http://docs.python.org/library/logging.html#basic-example the default behaviour of %(asctime)s is to produce output of the form “2003-07-08 16:49:45,896” but a datefmt of %Y-%m-%d %H:%M is specified which account for the above behaviour. My proposed solution is to simply remove the datefmt parameter in the call to logging.basicConfig and use the default behaviour which is much more useful. i.e.

...
 29 # Log everything to the logfile
 30 #logging.basicConfig(format=format, level=logging.DEBUG, datefmt='%Y-%m-%d %H:%M', stream=os.fdopen(fd, 'a+'), filemode='w')
 31 logging.basicConfig(format=format, level=logging.DEBUG, stream=os.fdopen(fd, 'a+'), filemode='w')
 32
...

Testing this on a lucid installation worked perfectly. Please could this be reviewed by someone more familiar with the code and considered for inclusion in a future release.

Thanks,
Daniel

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.