question

laurenceh avatar image

Trying to add a new d-bus i2c service running at reboot, crashes the reboot sequence?


I am trying to get a new python d-bus service registered in Venus OS however when I try to do this the Reboot Crashes.

What could be going wrong?

Platform

Venus OS 2.60~22 as per this post:-

https://community.victronenergy.com/questions/50055/help-wanted-testing-new-raspberrypi-23-and-also-4.html

I am have a woking d-bus python script which interfaces with i2c and publishes Temperature and Humidity from a sensor to the D-Bus.

The i2c service

The script is based on the example script from this post.

https://github.com/victronenergy/dbus_vebus_to_pvinverter/blob/master/test/dummy_vebus.py

Here is the output from the working script

root@raspberrypi2:/media/sda4/dbus-i2c# ./dbus-i2c.py
INFO:root:./dbus-i2c.py is starting up
INFO:root:Loglevel set to INFO
INFO:root:registered ourselves on D-Bus as com.victronenergy.i2c
INFO:root:using device instance 0
Connected to dbus, and switching over to gobject.MainLoop() (= event based)
INFO:root:values now are temperature 23.2, humidity 37
INFO:root:values now are temperature 22.1, humidity 39.5

And the output using dbus -y

root@raspberrypi2:~# dbus -y com.victronenergy.i2c /Humidity/P GetValue
35.5
root@raspberrypi2:~# dbus -y com.victronenergy.i2c /Temperature/C GetValue
23.300000000000001
root@raspberrypi2:~# 

So that is all working

Configuration of a new service

I am following the instruction for configuring a new driver/service here.

https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus

Which says

For these situations, follow these steps:

  1. Set up your new driver under the /data disk so that it will survive software updates.
  2. Add a run script in your service's directory that daemon-tools can use to invoke your service.
  3. Optionally, add a log/run script that daemon-tools can use to turn on log management for your service. See the daemon-tools FAQ or another Venus service for an example of how to do this.
  4. Symlink your service directory to /service so that it will be invoked automatically at startup.
  5. Optionally, add some shell script logic to /data/rc.local to re-symlink your service if the symlink goes missing. rc.local is invoked at system startup and survives new Venus updates, whereas your symlink will not survive. By adding a check in rc.local you can ensure your service will be scheduled to start again after upgrade.

Here is what I have put in /opt/victronenergy/dbus-i2c

(The files i2c.py and .pyc are the library imported by dbus-i2c.py)

root@raspberrypi2:/media/sda4/dbus-i2c# ls
dbus-i2c.py   i2c.py        i2c.pyc       service       start-i2c.sh

Based on other services configured in Venus, here are the start, run and log/run files showing they are executable and all the service configuration I have set up.

.....#cat start-i2c.py
#! /bin/sh
exec $(dirname $0)/dbus-i2c.py

.....#ls -l 
-rwxr--r--    1 root     root          3234 May 27 12:17 dbus-i2c.py
-rwxr-xr-x    1 root     root          2507 May 27 12:16 i2c.py
-rw-r--r--    1 root     root          1976 May 27 20:24 i2c.pyc
drwxr-xr-x    4 root     root          4096 May 27 11:57 service
-rwxr-xr-x    1 root     root           199 May 27 13:15 start-i2c.sh

....# cat service/run
#!/bin/sh
exec 2>&1
exec softlimit -d 100000000 -s 1000000 -a 100000000 /opt/victronenergy/dbus-i2c/start-i2c.sh

....# cat service/log/run
#!/bin/sh
exec 2>&1
exec multilog t s99999 n8 /var/log/dbus-i2c

....# ls -l service
drwxr-xr-x    3 root     root          4096 May 27 11:57 log
-rwxr-xr-x    1 root     root           113 May 27 13:10 run
drwx------    2 root     root          4096 May 27 13:15 supervise.    

....# ls -l /service/dbus-i2c
lrwxrwxrwx    1 root     root            35 May 27 12:21 dbus-i2c -> /opt/victronenergy/dbus-i2c/service



Also when I accidentally had errors in the run and /log/run files, the error logs in /var/log/dbu-i2c were recording the error correctly.

What currently happens

On reboot the screen displays the Victron energy logo screen and a flashing cursor, it never drops to a command line prompt or any onscreen reports.

Also the internet does not come up (no response to ping) so I can not SSH into the device.

A USB keyboard also has no effect.

I have started the RPi with another Venus OS SD card and mounted the non working card there is no dbus-i2c directory in /var/log (which was there when there were errors in the run and log/run files.)

I don't know where to go next to get this running?



Venus OSRaspberry Pid-busdriver
5 comments
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

I'm really at a loss as to what to do.....

When I make the softlink in /service/dbus-i2c ==> /opt/victronenergy/dbus-i2c/service

The service starts immediately I don' see4m to need to do anything more to make this happen. The service can be configured down and up again using svc -d and -u. I have removed the start-i2c.sh and linked /service/run directly to start the python script. I have also tried checking if the script is running with pgrep and making sure we don't start it a second time. I have tried checking that /dev/i2c-1 exists with if ! -e /dev/i2c-*

I have tried everything. What happens is that the service starts (when I create the soft link in /service) and I can use it for many hours. But when I try to reboot the reboot hangs and the system will not come up. I have to mount the SD card and make some changes (to /data/rc.local remove the soft link in /services remove the soft link from /opt/victronenergy/dbus-i2c ==>/data/dbus-i2c and try various other things) at some point while trying these changes the system decides it will now reboot from the SD card but there seems to be no deterministic fix, I wonder if I'm hitting some sort of race condition in the reboot?

I need help?

Should I try a production release not 2.60~22 ?


Hi, I dont know what could be wrong.

To see the details, use a serial console. Ie what is explained here:


https://github.com/victronenergy/venus/wiki/raspberrypi-install-venus-image#serial-console


and yes, for sur trying the production image is a good idea

laurenceh avatar image laurenceh mvader (Victron Energy) ♦♦ ·

Matthijs:

Thanks for the response -

Even if you not sure of the problem it reassures me I'm not doing anything silly or impossible.

It new seems it might have been a slowly degrading file system (perhaps from too many power downs and reboots while trying to debug the startup). Anyway the Venus console started to report corrupted media so I reinstalled a clean 2.60~22 image and started again. This time it seems to have started up OK (or at least in a repeatable fashion).

A few bits of defensive programming to be implemented

-catching death of a thread

-Making sure the device has started before trying to read it

But it is starting to behave as I expect.

Hey I´m trying to do something similar, did you get it right?

laurenceh avatar image laurenceh mateo-perez-de-gracia ·

Yes the occurrence has reduced, I think the problem is if anything is writing to the card as the power is removed most likely logs. Also the latest release 2.57 has a new version of Linux which includes a power off command which I use from the console to to shut down more gracefully.

Useful note while developing, if there is a file named ‘down’ in the service directory the service system does not start the service on power up so you can issue svc -u when your ready.

It would however be nice if the Venus settings had a power off as well as the reboot option.

Longer term, I am looking at the USB auto mount system to try to mount a device on /var/log if it has a particular volume name. Then if the logger is writing to a log when power goes down it will only be an external memory stick that gets damaged not the core SD card.


Also of course I have also learnt to take more backups and my scripts to restore modifications on a clean install only takes a couple of minutes.





0 Answers