Zim

[0.46] [Win32]: "No handlers could be found for logger 'zim.fs'"

Bug #562111 reported by Brendan Kidwell on 2010-04-13
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zim
High
Unassigned

Bug Description

confirmed in lp:zim revisions 221 (0.46) and 225
platform: Windows

Zim always says "No handlers could be found for logger 'zim.fs'" in log file at some point during execution but otherwise seems to work okay. During exit, Zim tells you an error occurred and this is all that shows up in the log file.

Occurs when running compiled zim.exe from ./windows/build-win32.py but not when running zim.py under python.exe.

Incidentally, I couldn't figure out how to get zim.exe to produce "--debug" output.

TO REPRODUCE:
1. Get lp:~bkidwell/zim/pyzim-win-installer . (This is currently based upon lp:zim rev 221, the version 0.46 milestone.)
2. Follow instructions in windows/README-BUILD-win32.txt but you may omit any parts dealing with NSIS -- you only need to compile Zim using py2exe.
3. Run windows/zim/zim.exe .

summary: - Win32: "No handlers could be found for logger 'zim.fs'"
+ [0.46] [Win32]: "No handlers could be found for logger 'zim.fs'"

This error means there is some logging being used before logging is configured. Configuration happens early on zim.__init__.py main() .

My suspicion is that somehow in the compiled version modules are loaded in a different order so a warning is emitted before this main() function is called.

You can try putting the following code at the start of zim.py and compile it again:

  import logging
  logging.basicConfig()

Hope this helps.

Changed in zim:
status: New → Confirmed
importance: Undecided → High

Found it - not sure how I could have overlooked it with my previous check.

Cause is this warning in zim/fs.py :

try:
 import xdg.Mime as xdgmime
except ImportError:
 logger.warn("Can not import 'xdg.Mime' - falling back to 'mimetypes'")
 import mimetypes

which only occurs on windows (assuming we always have xdg.Mime installed on linux).

Fix as in comment #1, will put the fix in the main trunk.

Fix committed in rev233 - untested with compiled executable on windows, but pretty sure this will work.

Changed in zim:
status: Confirmed → Fix Committed
Brendan Kidwell (bkidwell) wrote :

Sorry Jaap, I'm not seeing it. I just merged my branch from yours and tried running a fresh build.

The problem doesn't seem to be fixed, and when I look at the history for lp:zim online I you didn't touch fs.py anywhere near 4 May. Did you forget to check something in, or am I doing it wrong?

Brendan Kidwell (bkidwell) wrote :

I decided (for now anyway) to just patch fs.py so that if the error occurs (comment #2) and the os is Windows, just ignore it. Is this the appropriate solution?

I'll be pushing this to my windows branch later tonight along with other progress.

On Mon, May 24, 2010 at 12:01 AM, Brendan Kidwell <email address hidden> wrote:
> Sorry Jaap, I'm not seeing it. I just merged my branch from yours and
> tried running a fresh build.
>
> The problem doesn't seem to be fixed, and when I look at the history for
> lp:zim online I you didn't touch fs.py anywhere near 4 May. Did you
> forget to check something in, or am I doing it wrong?

The fix is in zim.py itself. Logging is set up earlier now so the
logger is in place when fs.py is loaded. This should remove the error
that no handler was found.

Brendan Kidwell (bkidwell) wrote :

Yes, thanks for clearing that up. There's a side issue that I routed around in my additional patch by saying "if OS is Windows, ignore this error and don't log it":

If Zim has anything Errors or Warnings to say, in Windows, these are written to the log file and every time you quit if the log file isn't empty, you get a popup message. My understanding is that on unix, Zim writes to the standard error channel and the desktop generally discards the output.

So what should we do about all these non-fatal errors? Can we configure the logger to just shut up about warnings unless the user provides a command line switch turning them on?

On Tue, May 25, 2010 at 4:36 PM, Brendan Kidwell <email address hidden> wrote:
> So what should we do about all these non-fatal errors? Can we configure
> the logger to just shut up about warnings unless the user provides a
> command line switch turning them on?

Sure you can set the logging level to ERROR and warnings will not be
shown. Would like to do this only when compiling the executable, not
by default.

Check the code for -V and -D which set the logging level to INFO and DEBUG.

-- Jaap

Brendan Kidwell (bkidwell) wrote :

Moved the idea from comments 7 and 8 to lp:587686 .

Fix released in zim 0.47

Changed in zim:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers