Miner not ready to get P2P Status

[controllinohelium]

Log throws the following error:

@config:diagnostics:225 Miner not ready to get p2p status

So we are having a similar Issue as #70 but the solutions mentioned there didn't work. When we do... dbus-send --system --print-reply --dest=com.helium.Miner / com.helium.Miner.P2PStatus it outputs... Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.helium.Miner was not provided by any .service files

What could be the reason here? It seems that some .service file is missing, but we are quite unsure what the contents of this service file should be. Do you have an example of the service that needs to be applied?

Solutions we have tried so far:

• Checked if we added the com.helium.Miner.conf to /etc/dbus-1/system.d/. We have.
• Checked if the use_ebus variable in our docker.config is set to true. It is.
• Checked if container has proper access to dbus. It has (probably):

docker run -d --init \ --ulimit nofile=524288:524288 \ --restart always \ --publish 1680:1680/udp \ --publish 44158:44158/tcp \ --name miner \ --mount type=bind,source=/home/pi/miner_data,target=/var/data \ --device /dev/i2c-1 \ --net host \ --privileged \ -v /var/run/dbus:/var/run/dbus \ --env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/var/run/dbus/system_bus_socket \ --mount type=bind,source=/home/pi/docker_config/docker.config,target=/opt/miner/releases/0.1.0/sys.config \ quay.io/team-helium/miner:latest-arm64

[madninja]

1. Are you sure those locations for /var/run/dbus and the DBUS_SYSTEM_BUS_ADDRESS are correct and exist on the host system
2. the location of that service file is: https://github.com/helium/miner/blob/master/config/com.helium.Miner.conf . You'll have to put that in the right place for dbus to pick that up. Usually that is somewhere under /etc/dbus-1/... but please check your dbus-daemon man pages for where to locate that on your host

[controllinohelium]

Hi @madninja - thanks for your prompt reply.

1. Actually there are multiple locations on our host system (RPi OS / Debian) that we found: /var/run/dbus /run/dbus Both contain _system_bussocket

2. Yes, we put the com.helium.Miner.conf into multiple available locations that we found. /usr/share/dbus-1/system.d /etc/dbus-1/system.d

Do you have any other ideas what it could be?

[madninja]

Well if one path binding didn't work did you try the other one?

[controllinohelium]

Yes, we already tried that, no luck whatsoever.

[madninja]

And you restarted dbus and miner after placing the service file in the right location?

I would try to get that working first and be able to use that dbus command:

dbus-send --system --print-reply --dest=com.helium.Miner / com.helium.Miner.P2PStatus

from the miner docker, or the host system, to see if the miner is setup correctly

[controllinohelium]

Yes, we restarted dbus as well as miner after placing the .conf file in the right location, even went that far to reboot the whole system every time we changed it. It's really frustrating, unfortunately.

We use the miner docker, so you mean we should do that command also within the container itself (docker exec -it miner /bin/sh and running the command)? Unfortunately, it leads to the same result.

[madninja]

so if you run that dbus command in the miner docker itself it has that problem too? That means you're either not running dbus, use_ebus is really not set to true somehow, or the miner is failing to register with dbus. Look in the logs around miner startup to see if you see any ebus/dbus errors?

also make sure that the miner docker has access to all the same dbus folders since it needs dbus write access to register itself.

[controllinohelium]

1. Checked the config within the docker container, use_ebus is set to true.

2. dbus is apparently running (the first line?), did ps -ef | grep dbus and got the following output: message+ 418 1 0 15:50 ? 00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only pi 8549 6730 0 16:38 pts/0 00:00:00 grep --color=auto dbus

3. Will run docker exec miner tail -F /var/data/log/console.log | grep ebus and docker exec miner tail -F /var/data/log/console.log | grep dbus to see what's the output, first command is running but it takes a while that something shows up, I guess.

[controllinohelium]

@madninja strangely I can't seem to find any ebus or dbus errors within console.log and error.log also shows nothing... shouldn't there be something that hints to "dbus" or "ebus" in one of these files at least? I again double-checked if we have set use_ebus to true, and it is absolutely true.

[controllinohelium]

Okay, I moved one step further. On the docker run command, I changed --mount type=bind,source=/home/pi/docker_config/docker.config,target=/opt/miner/releases/0.1.0/sys.config to --mount type=bind,source=/home/pi/docker_config/docker.config,target=/opt/miner/releases/2021.09.16.1/sys.config to change the sys.config of the latest miner image release, and not (for whatever reason) the 0.1.0 version.

Now, within the Docker Container, I get a good-looking output. method return time=1632240575.842641 sender=:1.37 -> destination=:1.39 serial=4 reply_serial=2 array [ struct { string "connected" string "no" } struct { string "dialable" string "no" } struct { string "nat_type" string "unknown" } struct { string "height" string "1" } ]

But on the Host System, I get the following: Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

EDIT: I managed to get 1 reply from the dbus-send command also on the Host System, but now I get "NoReply" Errors again. Is this how it should behave? Anyway, thank you for your help @madninja - I think we moved further now :-)

[madninja]

Glad you're in mostly working setup. Yes you need to use the release version n the bind for sys.config.

Usually you'll have NoReply errors for a while, while the miner syncs the snapshot it is very busy. Once that passes it should behave normally.

[controllinohelium]

Okay, thank you a lot @madninja - it indeed behaved normally after a while.