Cerbo GX /data partition filled up with PHP session files

Beta testing Venus OS beta testing
1

Out of the blue, after running my system for more than a year without problems, I got the following alarms:

'BMS lost' on 'VE.Bus System [276]'
'Low battery' on 'VE.Bus System [276]'

The low battery LED of the MultiPlus II was on and it had switched to pass-through. But the battery was fine and continued to report its status via CAN to the Cerbo. However, the VE.bus communication between the Cerbo and Multiplus II seemed to be lost.

I couldn’t find anything, and finally decided to reboot the Cerbo (v3.70~54) which cleared the alarms. But the problem came back the next day.

At that point, I noticed that the firmware check also didn’t work anymore: the check button was greyed out. The log file was missing and /var/log/messages showed the reason:
Dec 28 02:05:00 einstein cron.info CROND[5500]: (root) CMDOUT (multilog: fatal: unable to write to /data/log/swupdate/current: out of disk space)

There was plenty of disk space:

root@einstein:/data# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.1G    986.2M     17.5M  98% /
devtmpfs                453.9M         0    453.9M   0% /dev
tmpfs                   502.4M    864.0K    501.6M   0% /run
tmpfs                   502.4M    272.0K    502.2M   0% /var/volatile
/dev/mmcblk1p5            4.6G      1.3G      3.1G  29% /data
tmpfs                   502.4M    864.0K    501.6M   0% /service
overlay                 502.4M    272.0K    502.2M   0% /var/lib

However, there were no more i-nodes:

root@einstein:/data# df -h -i
Filesystem              Inodes      Used Available Use% Mounted on
/dev/root               297.3K     55.7K    241.6K  19% /
devtmpfs                113.5K       338    113.2K   0% /dev
tmpfs                   125.6K       908    124.7K   1% /run
tmpfs                   125.6K       146    125.5K   0% /var/volatile
/dev/mmcblk1p5          305.9K    305.9K         0 100% /data
tmpfs                   125.6K       908    124.7K   1% /service
overlay                 125.6K       146    125.5K   0% /var/lib

I found a directory with 309005 files in it:

root@einstein:/data/var/lib/venus-www-sessions# ls | wc
   309005    309005  11742190
root@einstein:/data/var/lib/venus-www-sessions# ls -ltr | less
-rw-------    1 php-fpm  php-fpm         32 Sep  9 16:55 sess_e80bba1d4622f3d9bc6ca551f7b7ba3e
-rw-------    1 php-fpm  php-fpm         32 Sep  9 16:55 sess_92ed02d728a95f954b59fb249821b3ce
-rw-------    1 php-fpm  php-fpm         32 Sep  9 16:56 sess_efee5ef104e8b1501130015f232012d1
[...]
-rw-------    1 php-fpm  php-fpm         32 Dec 26 01:03 sess_c2e57c21a072a865b03880d2ee81d577
-rw-------    1 php-fpm  php-fpm         32 Dec 28 07:58 sess_7fbbb52b50f79383610da3e67ee86315
-rw-------    1 php-fpm  php-fpm         32 Dec 28 15:00 sess_f700eea964c039658dae748054e223c9
root@einstein:/data/var/lib/venus-www-sessions# cat -n sess_e80bba1d4622f3d9bc6ca551f7b7ba3e
     1  remoteconsole-authenticated|b:1;

It turns out that these files are created by the http server for the local GUI. It creates about 2 files per minute, even after all connections are terminated! I upgraded to v3.70~61, but the behavior remains the same.

Why are these session files constantly being created? Why are they created on a disk that only allows a limited number of writes? Why are they not cleaned up?

2

I just checked my Cerbo (v 3.66) and sat watching it for a few minutes (the i-nodes did not increase)

Screenshot 2025-12-29 145122
Screenshot 2025-12-29 145122560×128 3.92 KB

3

I have some more information regarding my first question. I installed tcpdump and strace binaries and found out that every minute the nginx web server receives the following HTTP requests:

> GET /solar_api/v1/GetActiveDeviceInfo.cgi?DeviceClass=Inverter HTTP/1.1 (IPv4)
< HTTP/1.1 404 Not Found

> GET /auth/test.php?user=remoteconsole HTTP/1.0 (IPv6)
< HTTP/1.1 200 OK
< Server: nginx/1.24.0
< Date: Tue, 30 Dec 2025 09:24:36 GMT
< Content-Type: text/html; charset=UTF-8
< Connection: close
< Vary: Accept-Encoding
< X-Powered-By: PHP/8.2.29
< Set-Cookie: VENUS_SESSION_ID=1b25fc6c1b1c67c7284aa083f5e9e9d2; expires=Wed, 30 Dec 2026 09:24:36 GMT; Max-Age=31536000; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Cache-Control: no-cache

> GET /solar_api/v1/GetInverterInfo.cgi HTTP/1.1 (IPv4)
< HTTP/1.1 404 Not Found

> GET /auth/test.php?user=remoteconsole HTTP/1.0 (IPv4)
< HTTP/1.1 200 OK
< Server: nginx/1.24.0
< Date: Tue, 30 Dec 2025 09:24:36 GMT
< Content-Type: text/html; charset=UTF-8
< Connection: close
< Vary: Accept-Encoding
< X-Powered-By: PHP/8.2.29
< Set-Cookie: VENUS_SESSION_ID=242b03cb356e52f7352b16b8b61287d1; expires=Wed, 30 Dec 2026 09:24:36 GMT; Max-Age=31536000; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Cache-Control: no-cache

The requests for /solar_api/... originate from dbus-fronius. I’m running a Modbus proxy for my SolarEdge inverter on the Cerbo to allow multiple connections to it, so I’ve configured the IP of my PV inverter as 127.0.0.1. Apparently, the dbus-fronius process polls the HTTP port of the inverter in addition to the Modbus port.

I don’t understand how this all works, but somehow, the nginx web server generates /auth/test.php?user=remoteconsole requests to itself in response to the (failed) requests for /solar_api/..., once for IPv4 and once for IPv6. As a result, two PHP session files are created and never removed. And as far as I can see, the PHP session cookie is only returned to the nginx server, not to the dbus-fronius process.

1 Like
4

In fact, every HTTP request to the cerbo on port 80 results in one or more new session files in /data/var/lib/venus-www-sessions.

5

Same problem here…

I had to delete the contents of the /data/var/lib/venus-www-sessions/ directory because the /usr/sbin/start-nginx.sh script never finished executing, preventing the nginx service from starting.

It had so many files that the ls command couldn’t even display them…

I’ve added rm -rf /data/var/lib/venus-www-sessions/ at the beginning of the create-venus-session-dir script.

6

This mistreats the internal storage because it involves many writes per minute, completely pointless!!

7

Hi all,

Thanks for your report - we’ll take care of this in an upcoming v3.70 beta version!

1 Like
8

Has it already been fixed in this release??

9

no not yet.

1 Like