openRC generic handling daemon

[cordelster]

@jblance I have a openRC implementation in addition to your systemd, though I have no idea how this may affect your CI, and as such I'm messaging you here rather than a PR.

Let me know how you would like me to forward it too you. It's tested out in alpine, in docker - alpine, platforms: x86_64, armhf, arm64(aarch64), and I have working builds in all aforementioned in standalone executable s.
It's stubbed out in my repo under openrc-dev.

[jblance]

the systemd implementation is pretty terrible in this work (the library I use requires re-compiling and headers) - so might be better to just PR it and I can look to fix whatever breaks

[cordelster]

And on another note, I'm still learning specially in the CI/CD realm of things, so any feedback when you have time would be fruitful an gladly accepted.

[jblance]

Im purely an amateur in all this - the code was something I needed that got extended for other peoples needs
But if you have questions that you think I might be able to help with, feel free to ask

[cordelster]

thanks - no really need to be considerate of the current outline, this codebase has grown to a level that its become a mess (hence the powermon work)

I wanted to ask about that, I'm glad you offered the answer. We are getting ready for fire season here, and this has been running on my RPi for almost a month. I figured the other changes that were clean up really would wait this push. If there is anything I can do just let me know. I'll start looking at powermon more going forward.

[jblance]

powermon is not ready for 'real' use currently, and Im still changing how i think it should work (ie I keep breaking it) but feel free to look and offer suggestions
currently (in powermon) Im trying to simplify it so it isnt as confusing

[cordelster]

I feel that! I'm personally satisfied with mppsolar, specially with all the recent additions. If it were me though I'd be following the same path looking for ways to simplify the front end. I think the only thing I would change is making a callback for certain settings that ask "are you sure you want to do this?" and allowing a override for any settings that could be catastrophic. Just something to remind you, that your playing with a setting you better double check.
When I seen the addition of prometheus push, and that you had refactored the daemon, I had no excuses left not to update my version, fix up where I left off, and make it openRC happy.
I'll sync powermon and see if there is any inspiration, I have not really looked at it other than to wonder it's direction or intent. You are doing wonderful work though.

[cordelster]

I probably should have done a better Feature List:
The OpenRC implementation provides:

✅ SIGTERM/SIGINT signal handling for clean shutdown
✅ PID file management with existence checking
✅ Optional psutil support for better process monitoring
✅ Auto-detection of systemd vs OpenRC systems
✅ Clean integration with your existing daemon abstraction

This will allow mpp-solar to run properly as a daemon on OpenRC systems (like Alpine Linux, Gentoo) while maintaining backward compatibility with systemd systems.

[cordelster]

I did find a couple things to clean up, so let me now when you plan to push a release so I can get you another PR. I have added the option of --pidfile since depending on the user running the service, may not have permission to write either /run or /var/run an I also added more checks and balances and sensible log and messages.
If I have no issues in the next week, I'll send the PR.

[jblance]

the release can wait if that suits - its pretty easy to do, so I dont mind either way

[cordelster]

I'm just chasing where the process forks, an the parent does not exit when entering the daemon. I should have it wrapped up soon.

[cordelster]

@jblance So I started up an earlier version I still have 0.16.29, I didn't expect to see a second process start, though it's there:
./mpp-solar-0.16.29 -C /etc/mpp-solar/mpp-solar.conf -D

/home/cdelasaux # ps -A |grep mpp-solar
 8983 root      0:00 ./mpp-solar-0.16.29 -C /etc/mpp-solar/mpp-solar.conf -D
 8984 root      0:00 ./mpp-solar-0.16.29 -C /etc/mpp-solar/mpp-solar.conf -D
 8986 root      0:00 grep mpp-solar

 # ./mpp-solar-0.16.29  -C /etc/mpp-solar/mpp-solar.conf -D
2025-05-30 00:49:59,831:INFO:__init__:main@205: Solar Device Command Utility, version: 0.16.29, python version: 3.11.8
2025-05-30 00:49:59,832:DEBUG:mqttbrokerc:__init__@29: mqttbroker config: {'name': 'localhost', 'port': 1883, 'user': None, 'pass': None}
2025-05-30 00:49:59,832:DEBUG:__init__:main@240: MqttBroker name: localhost, port: 1883, user: None
2025-05-30 00:49:59,833:DEBUG:__init__:main@242: udp port 5555
2025-05-30 00:49:59,833:DEBUG:__init__:main@244: Using Postgres None
2025-05-30 00:49:59,833:DEBUG:__init__:main@247: Using Mongo None with mppsolar
2025-05-30 00:49:59,846:DEBUG:__init__:main@278: args.configfile is true: /etc/mpp-solar/mpp-solar.conf
2025-05-30 00:49:59,854:DEBUG:__init__:main@321: device_class <class 'mppsolar.devices.mppsolar.mppsolar'>
2025-05-30 00:49:59,855:DEBUG:device:__init__@34: __init__ args () # ./mpp-solar-0.16.29  -C /etc/mpp-solar/mpp-solar.conf -D
2025-05-30 00:49:59,831:INFO:__init__:main@205: Solar Device Command Utility, version: 0.16.29, python version: 3.11.8
2025-05-30 00:49:59,832:DEBUG:mqttbrokerc:__init__@29: mqttbroker config: {'name': 'localhost', 'port': 1883, 'user': None, 'pass': None}
2025-05-30 00:49:59,832:DEBUG:__init__:main@240: MqttBroker name: localhost, port: 1883, user: None
2025-05-30 00:49:59,833:DEBUG:__init__:main@242: udp port 5555
2025-05-30 00:49:59,833:DEBUG:__init__:main@244: Using Postgres None
2025-05-30 00:49:59,833:DEBUG:__init__:main@247: Using Mongo None with mppsolar
2025-05-30 00:49:59,846:DEBUG:__init__:main@278: args.configfile is true: /etc/mpp-solar/mpp-solar.conf
2025-05-30 00:49:59,854:DEBUG:__init__:main@321: device_class <class 'mppsolar.devices.mppsolar.mppsolar'>
2025-05-30 00:49:59,855:DEBUG:device:__init__@34: __init__ args ()

Is it expected to have children to run MQTT?
I never noticed before as I know it's not related to my config sections or I would have 4 instances.
I guess I just never paid attention because well I never needed to, and I made some pore assumptions, that I need to fix in my daemon code to handle this ideally, so what forks a child?

[jblance]

i didnt think anything forked a child process - though I may have never really checked

[cordelster]

Okay let me know if you're seeing the same. It's possible though not likely, something in my environment. I spent all day chasing this, though the code is looking fairly elegant now, I had suspected it was something in my changes. Mean while, I'll spin up a fresh container and fresh hardware, and roll back abit just to get a baseline. LMAO
I obviously didn't expect any children, thought maybe I got to naughty with my code. ;)
Though you're going to get a bunch of debug logging in the process as far as the daemon code is concerned.
I'll dive into it in about 14 hours. I do love puzzles and challenges :D I'll be upset though if it's something in my environment. LOL

[cordelster]

Here is where I am currently, the fork happens very early (this code is in my openrc-dev branch and is current). I'll add some logging into the dummy daemon, as that's where it should be headed an update my branch.

# /usr/bin/mpp-solar --pidfile /run/mppsolard1.pid -C /etc/mpp-solar/mpp-solar.conf -D
2025-05-30 00:03:28,768:INFO:__init__:main@230: Solar Device Command Utility, version: 0.16.55, python version: 3.11.12
2025-05-30 00:03:28,771:INFO:__init__:log_process_info@280: [DAEMON_DISABLED_CREATED] PID: 9841, PPID: 9840, PGID: 9840, SID: 2382, Leader: False
2025-05-30 00:03:28,772:INFO:__init__:log_process_info@286: [DAEMON_DISABLED_CREATED] Command: /usr/bin/mpp-solar --pidfile /run/mppsolard1.pid -C /etc/mpp-solar/mpp-solar.conf -D
2025-05-30 00:03:28,772:INFO:__init__:main@385: Daemon DISABLED
2025-05-30 00:03:28,773:INFO:__init__:log_process_info@280: [AFTER_DAEMON_INITIALIZE] PID: 9841, PPID: 9840, PGID: 9840, SID: 2382, Leader: False
2025-05-30 00:03:28,773:INFO:__init__:log_process_info@286: [AFTER_DAEMON_INITIALIZE] Command: /usr/bin/mpp-solar --pidfile /run/mppsolard1.pid -C /etc/mpp-solar/mpp-solar.conf -D
2025-05-30 00:03:28,774:INFO:__init__:log_process_info@280: [AFTER_DAEMON_NOTIFY] PID: 9841, PPID: 9840, PGID: 9840, SID: 2382, Leader: False
2025-05-30 00:03:28,774:INFO:__init__:log_process_info@286: [AFTER_DAEMON_NOTIFY] Command: /usr/bin/mpp-solar --pidfile /run/mppsolard1.pid -C /etc/mpp-solar/mpp-solar.conf -D
2025-05-30 00:03:28,775:DEBUG:mqttbrokerc:__init__@29: mqttbroker config: {'name': 'localhost', 'port': 1883, 'user': None, 'pass': None}
2025-05-30 00:03:28,775:DEBUG:__init__:main@404: MqttBroker name: localhost, port: 1883, user: None
2025-05-30 00:03:28,775:DEBUG:__init__:main@406: udp port 5555
2025-05-30 00:03:28,776:DEBUG:__init__:main@408: Using Postgres None
2025-05-30 00:03:28,776:DEBUG:__init__:main@411: Using Mongo None with mppsolar
2025-05-30 00:03:28,788:DEBUG:__init__:main@466: args.configfile is true: /etc/mpp-solar/mpp-solar.conf
2025-05-30 00:03:28,797:DEBUG:__init__:main@511: device_class <class 'mppsolar.devices.mppsolar.mppsolar'>
2025-05-30 00:03:28,798:DEBUG:device:__init__@34: __init__ args ()
2025-05-30 00:03:28,798:DEBUG:device:__init__@35: __init__ kwargs {'name': 'Inverter_2', 'port': '/dev/ttyUSB2', 'protocol': 'PI30m045', 'outputs': 'prom_file', 'baud': 2400, 'porttype': None, 'mqtt_broker': <mppsolar.libs.mqttbrokerc.MqttBroker object at 0x7656f970>, 'udp_port': None, 'postgres_url': None, 'mongo_url': None, 'mongo_db': None, 'push_url': 'http://192.168.120.69:8428/api/v1/import/prometheus', 'prom_output_dir': '/var/lib/node-exporter/mppsolar'}

I should also mention it exits correctly:

2025-05-30 00:29:20,014:DEBUG:mqttbrokerc:publish@146: Publishing '{"name": "solar1 Total PV Generated Energy", "state_topic": "homeassistant/sensor/mpp_solar1_total_pv_generated_energy/state", "unique_id": "mpp_solar1_total_pv_generated_energy", "force_update": "true", "unit_of_measurement": "Wh", "device": {"name": "Inverter_1a", "identifiers": ["Inverter_1a"], "model": "Inverter_1a", "manufacturer": "MPP-Solar"}, "icon": "mdi:counter", "device_class": "energy", "state_class": "total_increasing", "last_reset": "2025-05-30 00:29:20.012678"}' to 'homeassistant/sensor/mpp_solar1_total_pv_generated_energy/config'
2025-05-30 00:29:20,515:DEBUG:mqttbrokerc:publish@146: Publishing '7558500' to 'homeassistant/sensor/mpp_solar1_total_pv_generated_energy/state'
2025-05-30 00:29:20,517:DEBUG:__init__:main@646: Not daemon, so not looping

# ps -ef | grep mpp-solar | grep -v grep
 9991 root      0:00 /usr/bin/mpp-solar --pidfile /run/mppsolard1.pid -C /etc/mpp-solar/mpp-solar.conf -D
 9992 root      0:01 /usr/bin/mpp-solar --pidfile /run/mppsolard1.pid -C /etc/mpp-solar/mpp-solar.conf -D
# pstree -p 9991
mpp-solar(9991)---mpp-solar(9992)---{mpp-solar}(9996)

I can easily accommodate the child in the daemon, it is just a quest to know why we have a child at this point just to be sure there is not something that needs looked at. Rather tackle sooner than later. as you can see, the second process crashes likely due to contention on the serial port, though it's never reported except once in a great while, I suspect because frequently it's the child process that is not in time for the port.

[cordelster]

It's my environment! I just never paid attention to processes running, nor tried to create/code a daemon in it. I have everything running from RAM on a Alpine based OS on a immutable Pi Zero, and because the the memory constraints, I build python and modules into self contained ELF files.

So how that works is python runs it's self first as the parent, then spawns mpp-solar, then in daemon mode, mpp-solar spawns a second instance of itself for a total of three PIDs, so in this case, I need too test to see if the module is running as a ELF, Allow the Python parent to run, and monitor the 3rd PID for supervision. I setup a docker instance to test in without needing to package an elf and there is no second instance unless the argument for daemon is given, as expected. So now with that lesson, I'll finish this up in a bit, since now I have to test both cases once I make the correct adjustments. SMH

[cordelster]

All the code is in place for the openRC style daemon and tested single an daemon runs.
#Added features:

• Can be fully supervised within openRC running daemon.
• Added --daemon-stop to shutdown the daemon, as such deleted the daemon helper script is moot.
• Added extensive debug logging.
• Configurable pid file.
• Creates /var/log/mpp-solar.log when running daemon.
• plus added some preprocess checks.

#Known issue

• Still working out making pyinstall elf mode more elegant and currently results in crashes trying to run daemon as a elf.

The functional code is still in my openrc-dev branch, I'm going to try to get the elf to behave , otherwise I'll revert that code to just allow multiple pid's in daemon for elfs.

[cordelster]

#536

I have done allot though I was hoping to get better behavior out of pyinstaller elf, though it is a little more complicated than I thought, so the code is there to work on, though disable and noted in mppsolar/init.py

Let me know if you would like me to change anything..

[cordelster]

I have completed and tested standard installations and PyInstaller elf packaging. Needs testing with a systemd environment and any tweaks you may want there. Evidently, making a daemon work within a pyinstaller bundle is extremely rare, an if anyone has done it, there is not any published information. So technically speaking, you now have the first pyinstaller capable daemon.
I have a few things to clean up, though I'm about to push my final update to the PR.

[cordelster]

@jblance So I cleaned this patch up a ton, honestly I was excited about pyinstaller packaged being functional, though this patch has the pyinstaller code commented out so it's not currently used in this patch, as there are some quarks I need to iron so that little errors like the comport being busy seems to be a roulette game where most the time it continues on, though occationally it does not. It's noted in init and anyone can just uncomment that section if they want to work on it. so the good thing is there is working openrc integration, and you accepting my mess, forced me to accelerate doing it right, an thus you have it sooner than you might have as the pressure was on so that your code is clean on the repo. :)

I can put some time into MQTT for commands if you wish.