Issue with Kotori on RaspberryPi (ARM)

Entwicklung / Development Fehleranalyse / Troubleshooting
1

I try to install Kotori on a debian. I follow the installation guide on hiveeyes.org but i have an issue when i start kotori.

this issue is:

2019-02-28 19:12:53,329  [root       ] INFO: Requested configuration files: /opt/kotori/.kotori.ini, /etc/kotori/kotori.ini
2019-02-28 19:12:53,334  [root       ] INFO: Expanded configuration files:  /opt/kotori/.kotori.ini, /etc/kotori/kotori.ini, /etc/kotori/apps-enabled/hives.ini
2019-02-28 19:12:53,339  [root       ] INFO: Used configuration files:      /etc/kotori/kotori.ini, /etc/kotori/apps-enabled/hives.ini
2019-02-28T19:12:53+0100 [kotori     ] INFO: Starting Kotori version 0.15.0
2019-02-28T19:12:53+0100 [kotori     ] INFO: Using configuration file /etc/kotori/kotori.ini
2019-02-28T19:12:53+0100 [kotori.core] INFO: Enabling applications ['hives']
2019-02-28T19:12:53+0100 [kotori.core] INFO: Starting application "hives"
2019-02-28T19:12:53+0100 [kotori.core] CRITICAL: Error loading entrypoint "kotori.daq.application.mqttkit:mqttkit_application"
2019-02-28T19:12:53+0100 [kotori.core] CRITICAL: Application entrypoint "kotori.daq.application.mqttkit:mqttkit_application" for "hives" not loaded
2019-02-28T19:12:53+0100 [kotori.core] INFO: Enabling vendors []

Can someone help me ?

I dont see where i make mistake.

Thanks

Georges

2

Dear @georges.gagliano,

thanks for writing in! Let’s check what might be going wrong with your setup, I will be happy to help. However, we will probably need to gather more information about this issue.

With kind regards,
Andreas.

3

I already learned your configuration hives.ini and it looks pretty straight-forward:

[hives]
enable      = true
type        = application
realm       = hives
mqtt_topics = hives/#
application = kotori.daq.application.mqttkit:mqttkit_application

So, we will have to investigate further what might go wrong on your machine.

4

Hm, are you running Kotori on ARM? I am assuming this as the version 0.15.0 display in your output was the latest one released for armhf [1].

Personally, I believe the configuration is completely okay, as Kotori does actually honor the settings fine by displaying:

2019-02-28T19:12:53+0100 [kotori.core] CRITICAL: Error loading entrypoint "kotori.daq.application.mqttkit:mqttkit_application"
2019-02-28T19:12:53+0100 [kotori.core] CRITICAL: Application entrypoint "kotori.daq.application.mqttkit:mqttkit_application" for "hives" not loaded

However, as there is no further output here, I don’t know what is actually going wrong here, so I will have to investigate further. Sorry that it doesn’t work out of the box for you. We will make it!

[1] Index of /hiveeyes/foss/debian/pool/main/k/kotori/

5

Dear @georges.gagliano,

after replicating the [hives] configuration snippet on my workstation after switching back to Kotori 0.15.0, everything seems to be totally fine.

So, I conclude the configuration is okay, but there’s something wrong with the installation of Kotori itself. May I humbly ask how you installed Kotori on your machine?

Thanks in advance,
Andreas.

P.S.: I can also confirm your configuration snippet would work with the most recent Kotori 0.21.1 release. So, there really/probably has to be something wrong with your setup. Let’s find out what this is about.

6

Dear Andreas

Thanks for your investigations.
Yes i have Kotori 0.15.0 on a raspiPI
I have following this doc Setup on Debian — Kotori 0.22.7 documentation to install Kotori.
I try next Week-end to reinstall on a fresh raspbian.

7

Thanks, Georges! Will still be happy to help but currently I don’t have a RaspberryPi running on my workbench ¹.

However, I believe @Thias and maybe also @Alex run instances of Kotori on their RaspberryPi machines. So I’m humbly asking whether one of you experienced similar things like @georges.gagliano when ramping up your DAQ backend setup?

¹ Should really get one up and running again to build a fresh Kotori 0.21.1 package for ARM.

8

Is there a difference between install kotori on Jessie or Stretch ?
Because in doc, there is a lot of reference to Jessie but nothing on stretch.

9

Yeah, then the Kotori armhf package has probably been built on Debian Jessie. This would also match my personal memories. But as Kotori presumably does start successfully on Stretch, I assume this is actually not the problem.

It looks like it can’t load its own Python modules properly. However, the log output lacks information about what went wrong when trying to load the application entrypoint kotori.daq.application.mqttkit:mqttkit_application.

Would it be possible that I could log in to the machine to investigate the problem hands-on?

10

yes it’s possible !

11

Ok, then let’s continue using PM. I’ll send you my ssh public key. Maybe I can catch the error.

12

ok when i have our ssh key i open access to my raspberry

13

Problem

Thanks, we already found the problem. It is reproduceable by issuing:

root@Framboise1:~# su - kotori
kotori@Framboise1:~ $ /opt/kotori/bin/python
>>> import kotori.daq.application.mqttkit
[...]
  File "/opt/kotori/lib/python2.7/site-packages/influxdb/client.py", line 16, in <module>
    from influxdb.line_protocol import make_lines, quote_ident, quote_literal
  File "/opt/kotori/lib/python2.7/site-packages/influxdb/line_protocol.py", line 12, in <module>
    from pytz import UTC
ImportError: No module named pytz

Looks like the early Kotori 0.15.0 package lacks this dependency.

Investigation

We expected a simple

kotori@Framboise1:~ $ /opt/kotori/bin/pip install pytz

to work by just installing the pytz package.

pip itself is broken

However, the attempt to install the pytz package yields another error like

Traceback (most recent call last):
  File "/opt/kotori/bin/pip", line 7, in <module>
    from pip import main
  File "/opt/kotori/lib/python2.7/site-packages/pip/__init__.py", line 73, in <module>
    from pip.util import get_installed_distributions, get_prog
  File "/opt/kotori/lib/python2.7/site-packages/pip/util.py", line 20, in <module>
    from distlib import version
  File "/opt/kotori/lib/python-wheels/distlib-0.1.9-py2.py3-none-any.whl/distlib/version.py", line 14, in <module>
  File "/opt/kotori/lib/python-wheels/distlib-0.1.9-py2.py3-none-any.whl/distlib/compat.py", line 31, in <module>
ImportError: cannot import name HTTPSHandler

By following python - ImportError: cannot import name HTTPSHandler using PIP - Stack Overflow we also found that

import ssl

would also error out like

kotori@Framboise1:~ $ /opt/kotori/bin/python -mssl
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.7/ssl.py", line 98, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: libssl.so.1.0.0: cannot open shared object file: No such file or directory

So we conclude binary compatibility between Debian Jessie and Debian Stretch is not given due to conflicts regarding the OpenSSL version. In turn, this breaks pip completely.

Damn. We really should provide packages built on/for Debian Stretch.

Solution

So, let’s just download the single missing package pytz · PyPI from PyPI:

su - kotori
cd /tmp
wget https://files.pythonhosted.org/packages/af/be/6c59e30e208a5f28da85751b93ec7b97e4612268bb054d0dff396e758a90/pytz-2018.9.tar.gz
tar -xzf pytz-2018.9.tar.gz
cd pytz-2018.9/

and install it using the basic Python package setup mechanism without even touching pip at all:

/opt/kotori/bin/python setup.py install

Installed /opt/kotori/lib/python2.7/site-packages/pytz-2018.9-py2.7.egg
Processing dependencies for pytz==2018.9
Finished processing dependencies for pytz==2018.9

Proof

Start Kotori ad hoc in the foreground

su - kotori
/opt/kotori/bin/kotori --config /etc/kotori/kotori.ini
2019-03-02T03:09:33+0100 [kotori.core                  ] INFO: Enabling applications ['hives']
2019-03-02T03:09:33+0100 [kotori.core                  ] INFO: Starting application "hives"
2019-03-02T03:09:39+0100 [kotori.daq.graphing.grafana  ] INFO: Starting GrafanaManager "GrafanaManager". grafana=localhost:3000
2019-03-02T03:09:39+0100 [kotori.daq.services.mig      ] INFO: Starting MqttInfluxGrafanaService. name=service-mig-hives, channel={'realm': 'hives', 'mqtt_topics': 'hives/#', 'enable': 'true', 'type': 'application', 'application': 'kotori.daq.application.mqttkit:mqttkit_application'}
2019-03-02T03:09:39+0100 [kotori.daq.intercom.mqtt.base] INFO: Starting PahoMqttAdapter. name=mqtt-hives, broker=localhost:1883, object=<kotori.daq.intercom.mqtt.paho.PahoMqttAdapter object at 0x74319950>
2019-03-02T03:09:39+0100 [kotori.core                  ] INFO: Enabling vendors []
2019-03-02T03:09:39+0100 [kotori.daq.intercom.mqtt.paho] INFO: Subscribing to topics [u'hives/#']. client=<paho.mqtt.client.Client object at 0x74319b90>
2019-03-02T03:09:39+0100 [kotori.daq.intercom.mqtt.paho] INFO: Subscribing to topic 'hives/#'
2019-03-02T03:09:41+0100 [kotori.daq.services.mig      ] INFO: [hives       ] transactions: 0.00 tps
[...]
CTRL+C

Restart Kotori service

root@Framboise1:~# systemctl restart kotori

root@Framboise1:~# tail -F /var/log/kotori/kotori.log
2019-03-02T03:17:33+0100 [kotori                             ] INFO: Starting Kotori version 0.15.0
2019-03-02T03:17:33+0100 [kotori                             ] INFO: Using configuration file /etc/kotori/kotori.ini
2019-03-02T03:17:33+0100 [kotori.core                        ] INFO: Enabling applications ['hives']
2019-03-02T03:17:33+0100 [kotori.core                        ] INFO: Starting application "hives"
2019-03-02T03:17:34+0100 [kotori.daq.graphing.grafana        ] INFO: Starting GrafanaManager "GrafanaManager". grafana=localhost:3000
2019-03-02T03:17:34+0100 [kotori.daq.services.mig            ] INFO: Starting MqttInfluxGrafanaService. name=service-mig-hives, channel={'realm': 'hives', 'mqtt_topics': 'hives/#', 'enable': 'true', 'type': 'application', 'application': 'kotori.daq.application.mqttkit:mqttkit_application'}
2019-03-02T03:17:34+0100 [kotori.daq.intercom.mqtt.base      ] INFO: Starting PahoMqttAdapter. name=mqtt-hives, broker=localhost:1883, object=<kotori.daq.intercom.mqtt.paho.PahoMqttAdapter object at 0x740f3b90>
2019-03-02T03:17:34+0100 [kotori.core                        ] INFO: Enabling vendors []
2019-03-02T03:17:34+0100 [kotori.daq.intercom.mqtt.paho      ] INFO: Subscribing to topics [u'hives/#']. client=<paho.mqtt.client.Client object at 0x740f3dd0>
2019-03-02T03:17:34+0100 [kotori.daq.intercom.mqtt.paho      ] INFO: Subscribing to topic 'hives/#'

Enjoy!

2 Likes
14

Sorry for the inconveniences you had when starting with the DAQ backend. As mentioned above, we really should provide packages built on/for Debian Stretch. In the meanwhile, your instance should hopefully work properly - at least Kotori would start up successfully now.

However, we really can’t guarantee that the old version of Kotori will work together with the most recent Grafana version. So, please let us know about any other obstacles you might encounter during the next steps of your journey.

15

Dear Andreas

Thanks a lot for your help !!!

Can you tell me quickly what you do to solve this issue ?

Thanks

Georges

16

… wasn’t it …

17

Sure.

Reason

Kotori 0.15.0 (armhf) obviously lacks and doesn’t install one of its important dependencies, the pytz package from the Python Package Index.

Solution

As pip - the package installer - is also broken (sorry for that), we just download the sdist package directly from PyPI and install it manually into the Python virtualenv Kotori is shipping itself with.

Fixing the issue is just a matter of.

# Change user
su - kotori

# Download and extract Python sdist package
cd /tmp
wget https://files.pythonhosted.org/packages/af/be/6c59e30e208a5f28da85751b93ec7b97e4612268bb054d0dff396e758a90/pytz-2018.9.tar.gz
tar -xzf pytz-2018.9.tar.gz
cd pytz-2018.9/

# Install package
/opt/kotori/bin/python setup.py install

# Restart service (as root user)
systemctl restart kotori

Background

Please note that this error actually doesn’t reveal itself easily and we feel sad about the fact you ran into this, as others might also have, probably us as well ;]. The situation has already been improved with a more recent version of Kotori:

With the current version, Kotori would have yielded the corresponding exception

[...]
  File "/opt/kotori/lib/python2.7/site-packages/influxdb/client.py", line 16, in <module>
    from influxdb.line_protocol import make_lines, quote_ident, quote_literal
  File "/opt/kotori/lib/python2.7/site-packages/influxdb/line_protocol.py", line 12, in <module>
    from pytz import UTC
ImportError: No module named pytz

into its logfile at /var/log/kotori/kotori.log.

Conclusion

So, we really should get our sh… together and build fresh packages suitable to be installed on Debian Stretch, likewise for both amd64 and armhf architectures.

18

A post was split to a new topic: Fresh Debian packages for running Kotori on ARM

19

Dear @georges.gagliano,

after trying to improve things based on your experiences, we just released Kotori 0.22.6 [1] for "amd64" and "armhf". Thanks again for telling us about the issues you were having.

With kind regards,
Andreas.

[1] Kotori 0.22.6 released

20

Dear @Andreas
I upgrade kotori and everything is OK !
I also try a new installation to confirm that the installation procedure presented on the site works.
Thanks for all