proxy of <Swig Object of type 'config_strlist *' at 0x7fedc716a690>

[SasanKSMC]

The following warning has started to appear using pythonmod since 1.9.3:

script <unboundmodule.config_strlist; proxy of <Swig Object of type 'config_strlist *' at 0x7fedc716a690> >

[gthess]

I think this logging may come from the python script itself. Can you check?

[SasanKSMC]

I'm confident that I have not enabled any extra logging compared to 1.9.2. It is the same script.

[gthess]

Is this the whole logged line? Also does it appear more than once?
By the way this seems like a (python) print of the object that holds the script's name. Not an actual warning/error.

[SasanKSMC]

yes it is the whole line. It appears once the unbound is loading and doesn't show up again while unbound is running.

[gthess]

Could you share the init function(s) from the python script?

[SasanKSMC]

def init(id, cfg):
    log_info("pythonmod: init called, module id is %d port: %d script: %s" % (id, cfg.port, cfg.python_script))
    return True

[gthess]

I suppose you also see the other part? pythonmod: init called, module id is ...

[gthess]

Could you also run:
unbound-control get_option "verbosity"
and
unbound-control get_option "python-script"
while unbound is running?

[SasanKSMC]

unbound -d -v -c /usr/local/etc/unbound/2.conf [1568579786] unbound[1870:0] notice: Start of unbound 1.9.3. [1568579786] unbound[1870:0] notice: init module 0: python [1568579786] unbound[1870:0] info: pythonmod: script loaded. [1568579786] unbound[1870:0] info: myScript: script <unboundmodule.config_strlist; proxy of <Swig Object of type 'config_strlist *' at 0x7f7dd14210> > [1568579786] unbound[1870:0] notice: init module 1: subnet [1568579786] unbound[1870:0] notice: init module 2: iterator [1568579787] unbound[1870:0] info: start of service (unbound 1.9.3).

[yds]

I'm having the same issue:

def init(id, cfg):
    log_info("pythonmod: init called, module id is %d port: %d script: %s" % (id, cfg.port, cfg.python_script))
    log_info("pythonmod: cfg.ifs: %s" % cfg.ifs)
    return True

logs this:

unbound[6104:0] info: pythonmod: init called, module id is 1 port: 53 script: <unboundmodule.config_strlist; proxy of <Swig Object of type 'config_strlist *' at 0x802002e40> >
unbound[6104:0] info: pythonmod: cfg.ifs: <Swig Object of type 'char **' at 0x802002de0>

prior to this issue cfg.python_script would return a str with the name of the configured python script. Now it seems like all of the config_file str type values return the Swig Object type instead of the value as per the config_file docs.

Here's a production script I've had working for years which now breaks on this line:

config = yaml.load(open(os.path.splitext(cfg.python_script)[0]+'.yml'), Loader=yaml.CSafeLoader)

% unbound-control get_option "python-script"
/usr/local/etc/unbound/views.py

[gthess]

This is a problem from 1.9.3 onwards when multiple python instances were introduced (#6).
The python_script is not a string anymore, instead it is a linked list of the available scirpts.
I will revisit the multi-python related behavior and also make this more easily accessible.

For now you could use python_script.str to access the filename given that you only use one python script.
If you use more, each script would need to know its order and traverse the linked list. python_script.next points to the next node (if any).

[yds]

Is there any documentation of this new pythonmod API? The config_file docs do not offer much of a clue on how to access the non-pythonic str type objects.

for example:

log_info("pythonmod: cfg.ifs: %s" % cfg.ifs)

outputs:

unbound[6104:0] info: pythonmod: cfg.ifs: <Swig Object of type 'char **' at 0x802002de0>

while config_file documents the cfg.ifs attribute is supposed to return:

Interface description strings (IP addresses).

I'm not sure if that's a list of strings or a sting of IP addresses (separated by?) -- either way Swig Object of type 'char **' does not offer much of a clue how to get information out of the config_file object.

If the API needs to change to accommodate running multiple python instances, would it be possible to keep the API more "Pythonic"? e.g. this str(python_script) NOT this python_script.str -- maybe make ``python_script` return a tuple of strings. It shouldn't be this convoluted to get at string values from within python is what I'm saying. ;-)

From my end user perspective it looks like #6 makes an undocumented way of using multiple python instances work while breaking the documented pythonmod API.

[gthess]

I am afraid there is no easy way now (without updating the Swig interface) to get the cfg.ifs values.
The same goes with the cfg.out_ifs.

As for the python_script.str way of getting the string, it is automatic type conversion from Swig; it just maps the C struct to Python. This should be fixed with a Swig interface update.

I'll work on that together with the other Python issues when I have some time, but not a top priority now.