Opened 7 years ago

Closed 6 years ago

#3003 closed defect (fixed)

datasrc_config_plugin.py crashes due to uncaught exception without datasrc.spec

Reported by: jinmei Owned by: vorner
Priority: medium Milestone: Sprint-20131001
Component: configuration Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: Unestimatable Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

If you move or remove the installed datasrc.spec
(located under e.g. /var/bind10/share/config_plugins/)
and start bind10, it immediately fails due to a crash of cfgmgr.
cfgmgr dies due to uncaught exception from the datasrc plugin:

Traceback (most recent call last):
  File "/Users/jinmei/opt/libexec/bind10/b10-cfgmgr", line 131, in <module>
    sys.exit(main())
  File "/Users/jinmei/opt/libexec/bind10/b10-cfgmgr", line 117, in main
    load_plugins(ppath, cm)
  File "/Users/jinmei/opt/libexec/bind10/b10-cfgmgr", line 76, in load_plugins
    module = imp.load_source(name, plugin)
  File "/Users/jinmei/opt/share/bind10/config_plugins/datasrc_config_plugin.py", line 25, in <module>
    spec = module_spec_from_file(path_search('datasrc.spec', PLUGIN_PATHS))
  File "/Users/jinmei/opt/lib/python3.2/site-packages/isc/util/file.py", line 29, in path_search
    raise IOError("'" + filename + "' not found in " + str(paths))
IOError: 'datasrc.spec' not found in ['/Users/jinmei/opt/share/bind10/config_plugins']

While it's basically an operation error, it at least shouldn't die
this way; it should catch the exception, complain about it and then
terminate itself.

Whether to treat it as a fatal error is a different question. In case
of plugin failures I'd be inclined to be lenient, but it may be debatable.

Subtickets

Change History (8)

comment:1 follow-up: Changed 7 years ago by vorner

Aren't we going to an extreme here already? I mean, we probably don't want to „recover“ from stuff like missing one of the python library files or .so files for C++ applications. In which way is this different?

Wouldn't it be better to have some generic way to catch the traces, turn them into some reasonable log messages, or so? Have a catch-all at the top-level python program, store the backtrace somewhere and put a fatal error into log?

comment:2 in reply to: ↑ 1 Changed 7 years ago by jinmei

Replying to vorner:

Aren't we going to an extreme here already? I mean, we probably don't want to „recover“ from stuff like missing one of the python library files or .so files for C++ applications. In which way is this different?

Wouldn't it be better to have some generic way to catch the traces, turn them into some reasonable log messages, or so? Have a catch-all at the top-level python program, store the backtrace somewhere and put a fatal error into log?

That can be a solution. My point is not to leak the exception up to
the interpreter level this way. There may even be a case where we
allow that - missing a critical python module on import, probably
because of installation error, could be one such case. But I don't
think it applies to this case. IMO it should be at least caught at
the top level, and may even have to not be considered fatal.

comment:3 Changed 7 years ago by muks

  • Estimated Difficulty changed from 0 to 3

comment:4 Changed 7 years ago by muks

  • Estimated Difficulty changed from 3 to Unestimatable

This ticket needs to be discussed on the mailing list.

comment:5 Changed 7 years ago by shane

As Mukund pointed out, if the intention is just to catch the exception at b10-cfgmgr we can estimate that.

comment:6 Changed 7 years ago by muks

  • Milestone changed from New Tasks to Sprint-20130903

comment:7 Changed 6 years ago by muks

  • Owner set to vorner
  • Status changed from new to assigned

comment:8 Changed 6 years ago by vorner

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed by the other ticket, now it looks like this (snippet from the logs):

2013-09-18 09:39:21.253 FATAL [b10-cfgmgr.util/25614] PYTHON_UNHANDLED_EXCEPTION program terminated with exception OSError: 'datasrc.spec' not found in ['/home/vorner/testing/bind10/share/bind10/config_plugins']. More info in /tmp/tmp73our7
Note: See TracTickets for help on using tickets.