DietPi-Software | WebIOPi: RPi 3/4 support + Python 3

[MichaIng]

Status: Ready

• Buster
• Stretch
• Bullseye

Reference: https://dietpi.com/phpbb/viewtopic.php?t=8945

Changelog: 8dd9cd5

Commit list/description:

• DietPi-Software | WebIOPi: Use newer fork to enable RPi 3 and RPi 4 support and make it a Python 3 only install. Remove the Python package(s) on uninstall as well.

[MichaIng]

@Joulinar
With this fork it works fine here. If you find time, could you test it on your RPi 1?

[Joulinar]

Let me see if I can do this today evening

[MichaIng]

Found another issue which might be related to the trouble torwan from the forum ran into. Stopping the service does not stop it. It's strange systemctl status webiopi shows that the stop command did run and it shows the correct PID from the PID file + "inactive (dead)", but via htop it can be seen that the process with this exact PID is still running, even with 100% CPU usage until it's being hard-killed (kill -9). This sysv => systemd translator seems to not do everything perfectly right here and we should create a native systemd unit instead.

That way we can also try to use a dedicated service user. It might however not be possible, depending on the tunables that this interface uses:

crw------- 1 root root 254, 0 Mar 28 22:27 /dev/gpiochip0
crw------- 1 root root 246, 0 Mar 28 22:27 /dev/gpiomem

---

Jep, no chance to run as non-root. But the hanging on stop seems to be related to the container. It hangs with systemctl-tty-ask-password-agent --watch which is typical for overlaps of host and container permissions and container not running on a real tty but a pts.

[Joulinar]

I was running into this issue on my test

[  OK  ] DietPi-Software | tar xf master.tar.gz
[  OK  ] DietPi-Software | rm master.tar.gz
[  OK  ] DietPi-Software | cd WebIOPi-master/WebIOPi-0.7.1
[ INFO ] DietPi-Software | patch -p1 -i webiopi-pi2bplus.patch, please wait...
/boot/dietpi/func/dietpi-globals: line 864: patch: command not found
[FAILED] DietPi-Software | patch -p1 -i webiopi-pi2bplus.patch

---

EDIT
apt install patch fixed it

[MichaIng]

Another test:

systemctl restart webiopi

Does it hang?

[Joulinar]

it took ages to complete but succeeded after quite some time. CPU was at 100% usage while restarting the service.

root@DietPi1:~# time systemctl restart webiopi.service

real    1m30.337s
user    0m0.104s
sys     0m0.058s
root@DietPi1:~#

root@DietPi1:~# journalctl -u webiopi.service
-- Logs begin at Thu 2019-02-14 11:12:01 CET, end at Wed 2021-04-28 00:35:00 CEST. --
Apr 28 00:29:54 DietPi1 systemd[1]: Started WebIOPi (DietPi).
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - Starting WebIOPi/0.7.1/Python3.7
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - GPIO - Native mapped to REST API /GPIO
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - Loading configuration from /etc/webiopi/config
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - Access protected using /etc/webiopi/passwd
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - HTTP Server binded on http://192.168.0.16:8002/
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - CoAP Server binded on coap://192.168.0.16:5683/
Apr 28 00:30:00 DietPi1 WebIOPi[376]: 2021-04-28 00:30:00 - WebIOPi - INFO - CoAP Server binded on coap://224.0.1.123:5683/ (MULTICAST)
Apr 28 00:33:28 DietPi1 WebIOPi[376]: 2021-04-28 00:33:27 - WebIOPi - INFO - Stopping...
Apr 28 00:33:28 DietPi1 systemd[1]: Stopping WebIOPi (DietPi)...
Apr 28 00:33:28 DietPi1 WebIOPi[376]: 2021-04-28 00:33:28 - WebIOPi - INFO - CoAP Server stopped
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: State 'stop-sigterm' timed out. Killing.
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: Killing process 376 (python3) with signal SIGKILL.
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: Main process exited, code=killed, status=9/KILL
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: Failed with result 'timeout'.
Apr 28 00:34:58 DietPi1 systemd[1]: Stopped WebIOPi (DietPi).
Apr 28 00:34:58 DietPi1 systemd[1]: Started WebIOPi (DietPi).
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - Starting WebIOPi/0.7.1/Python3.7
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - GPIO - Native mapped to REST API /GPIO
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - Loading configuration from /etc/webiopi/config
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - Access protected using /etc/webiopi/passwd
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - HTTP Server binded on http://192.168.0.16:8002/
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - CoAP Server binded on coap://192.168.0.16:5683/
Apr 28 00:35:00 DietPi1 WebIOPi[588]: 2021-04-28 00:35:00 - WebIOPi - INFO - CoAP Server binded on coap://224.0.1.123:5683/ (MULTICAST)
root@DietPi1:~#

[MichaIng]

Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: State 'stop-sigterm' timed out. Killing.
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: Killing process 376 (python3) with signal SIGKILL.
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: Main process exited, code=killed, status=9/KILL
Apr 28 00:34:58 DietPi1 systemd[1]: webiopi.service: Failed with result 'timeout'.

Okay, so it's not just me, it times out and is then hard killed. I remember seeing that issue with systemctl-tty-ask-password-agent --watch somewhere else already and a possible fix via systemd unit environment. It waits for a console input which is of course not possible from within a systemd unit. Dump that another systemd agent does not realise this 😄. I'll find a fix tomorrow, worst case a 2 seconds shutdown timeout.

[MichaIng]

Okay, systemctl-tty-ask-password-agent --watch is not the reason but a symptom along with the hanging stop of the process. It is always called together with systemctl as kinda precaution of anything did ask for certain permissions or not, but it does not hang any call and stops as fast as the underlying task finished.

Manually running python3 -m webiopi -c /etc/webiopi/config from console and attempting to interrupt it (CTRL+C) hangs the same way without any systemctl-tty-ask-password-agent --watch spawn. So it's an issue with WebIOPi itself, seen on Stretch, Buster and Bullseye.

Rules out any config issue and didn't find any additional hint in debug output: python3 -m webiopi -d
Ruled out container by running the same on directly on RPi.

Since it hangs with 100% CPU usage, and it does not write any file on the file system, I suggest to SIGKILL it simply immediately, so skipping the failing SIGTERM attempt. It's harsch but I don't see any risk or such this would apply. This app touches only kernel tunables/devices when using the web interface interactively, nothing else.

---

Same issue seems to be faced on the other little older fork: thortex/rpi3-webiopi#52 (+#53+#48)
And probably I should assure that also the original unpatched v0.7.1 is affected as well, leading to the complete failure on reinstall reported here: https://dietpi.com/phpbb/viewtopic.php?t=8945

[MichaIng]

Issue found and solved: thortex/rpi3-webiopi#57

Will open a PR at our fork as well. ...done: Freenove/WebIOPi#1

[Joulinar]

Well done @MichaIng

[MichaIng]

I can't believe it: WebIOPi reports to Google Analytics. The older fork has it recognised and removed, but the one we use not. Done now as part of the install process.

Whether or not a website/application reports to Google Analytics must be, even legally, the decision and responsibility of the website driver, NOT the web application developer. Imagine Wordpress or phpBB would add a hardcoded GA report, and finally all admins who run their own blog/forum with it would have their users reported to Google, which is quite a legal violation (without consent at least), at least in Europe. Okay, WebIOPi is usually not a public website, but this cannot be counted with, and it is NOT documented anywhere.

Now after 6 years no activity, no reason to make this any further topic, but my goodness it should have been long ago. Perfect example that open-source is no guarantee for anything 😉.

[MichaIng]

Ready now from my end, works fine, including web UI (without Google Analytics), toggling pins (which really change their status, verified via console tools like WiringPi) and service restarts.

[Joulinar]

Perfect example that open-source is no guarantee for anything 😉.

even open-source require someone who review/check and challenge thinks. Looks like you are the first one digging into the code 🤣

will do a final install on RPi1, but it will take time as the RPi1 is so incredible slow compare to a 4B 🙄

[MichaIng]

The other fork found it as well, although through Debian lintian build checks: cheating 😛: thortex/rpi3-webiopi#1
Kind of a coincidence in my case when adding debug code at various places 😄. I'd have been it earlier if my browser tracking blockers would have complained, but it didn't 🤔. Adding a custom rule now, let's see if it's true that 60% of the web uses GA.

[Joulinar]

AHHHH you deleted the branch eactly the moment I was running dietpi-update

 DietPi-Update
─────────────────────────────────────────────────────
 Phase: Installing new DietPi code

[FAILED] DietPi-Update | Downloading update archive
 - Command: curl -sSfLO https://github.com/MichaIng/DietPi/archive/webiopi.tar.gz

Ok took me a while to realize that but will use dev branch now 🤣

[Joulinar]

ok it is working on my RPi1 as well 👍