Journalctl - issuing lots of errors

Product support
1

I am trying to debug what my wifi AP keeps failing, and noticed that I am getting a lot of these errors in the

journalctl

Dec 08 16:07:12 0a97eb7 balenad[715]: time=“2018-12-08T16:07:12.632154239Z” level=warning msg=“failed to retrieve balena-engine-init version: exec: “balena-engine-init”: executable file not found in $PATH”
Dec 08 16:07:16 0a97eb7 balenad[715]: time=“2018-12-08T16:07:16.491691412Z” level=warning msg=“unknown container” container=e2292a46ffd5f5b87bb5198618960709a06cb42afba78c19450e8fa02fab5cda module=libcontaine>
Dec 08 16:07:16 0a97eb7 balenad[715]: time=“2018-12-08T16:07:16.670883797Z” level=warning msg=“unknown container” container=e2292a46ffd5f5b87bb5198618960709a06cb42afba78c19450e8fa02fab5cda module=libcontaine>
Dec 08 16:08:42 0a97eb7 balenad[715]: time=“2018-12-08T16:08:42.970761676Z” level=warning msg=“failed to retrieve balena-engine-init version: exec: “balena-engine-init”: executable file not found in $PATH”
Dec 08 16:10:13 0a97eb7 balenad[715]: time=“2018-12-08T16:10:13.315054730Z” level=warning msg=“failed to retrieve balena-engine-init version: exec: “balena-engine-init”: executable file not found in $PATH”
Dec 08 16:11:43 0a97eb7 balenad[715]: time=“2018-12-08T16:11:43.641212113Z” level=warning msg=“failed to retrieve balena-engine-init version: exec: “balena-engine-init”: executable file not found in $PATH”

What is causing this issue.?

My app that used to run fine as an AP , now quickly decays until the machines connecting to the AP can not longer get DNS lookups to work.

I am running :
v2.28.0
production

with SUPERVISOR VERSION

8.3.5

Thanks for any help you can offer

10

I backed the host and supervisor version back down to the following:

HOST OS VERSION Resin OS 2.15.1+rev1 production

SUPERVISOR VERSION 7.16.6

Also forgot to mention - this is a Raspberry Pi 3b+.

My application is stable again. I can use it as a WIFI AP to the internet. It remains stable and doesn’t decay under volume and/or over time as it was with the new version.

I am guessing there are significant changes to the host and/or supervisior between the 2 versions that impacts the dbus - network manager interface perhaps?

I am still getting errors - similar -

Dec 10 15:38:53 18718f9 healthdog[722]: time=“2018-12-10T15:38:53.590898355Z” level=warning msg=“unknown container” container=c67fed2fc0f86ec02af8a8f127317a88dbbc87c870a311314a2a023fa781bf59 module=libcontainerd namespace=plugins.moby

19

Hi @jayatrbt,

can you please tell us:

  • what are you trying to achieve and what’s the problem you’re trying to solve?
  • what device do you use?
  • are you using WiFi connect?
  • how are you setting up your AP?

Thanks!

22

Hi -

So I have a 5 different containers i am running. The one that ‘manages’ the wifi connection is based on a python script that I found.

#!/usr/bin/env python
import sys, imp
import dbus, uuid
imp.load_source(‘params’, ‘/data/net/params.py’)
import params

s_con = dbus.Dictionary({
‘type’: ‘802-11-wireless’,
‘autoconnect’: 1,
‘interface-name’: ‘wlan0’,
‘uuid’: str(uuid.uuid4()),
‘id’: params.SSID,
})

s_wifi = dbus.Dictionary({
‘ssid’: dbus.ByteArray(params.SSID),
‘mode’: ‘ap’,
‘band’: ‘bg’,
‘channel’: 11,
‘mac-address-randomization’:0
})

s_wsec = dbus.Dictionary({
‘key-mgmt’: ‘wpa-psk’,
‘psk’: params.PASSWORD,
‘proto’: [‘rsn’],
})

s_ip4 = dbus.Dictionary({‘method’: ‘shared’})
s_ip6 = dbus.Dictionary({‘method’: ‘auto’})

con = dbus.Dictionary({
‘connection’: s_con,
‘802-11-wireless’: s_wifi,
‘802-11-wireless-security’: s_wsec,
‘ipv4’: s_ip4,
‘ipv6’: s_ip6,
})

bus = dbus.SystemBus()

proxy = bus.get_object(“org.freedesktop.NetworkManager”, “/org/freedesktop/NetworkManager/Settings”)
settings = dbus.Interface(proxy, “org.freedesktop.NetworkManager.Settings”)

settings.AddConnection(con)

I have a python script I run before this, that deletes the active wifi connection… then i sleep 3 seconds , the i run this script.

This script generates chip errors in the journctl log if I run it with the new host and controller versions.

I believe the unknown container issues are from a separate issue in the containers, but being able to allow users to control sid , pwd, channel and band are key. And the new WIFI AP must forward requests like a traditional hotspot.

Thanks for your help!