no backup possible

[henrydiesner]

Unfortunately it is no System-Backup possible, the return is: "An internal error was detected in the service software. The diagnostics are being emailed to the service system administrator (root)." All parts of the system are in the newest version.

[jens-maus]

Please show the content of the file /var/tmp/cgimail.XXXX if this happens again

[henrydiesner]

In diesem Pfad ist leider nur diese Datei vorhanden:

Das E-Mail Add-on ist installiert und getestet.

Am 01.09.2017 um 21:37 schrieb Jens Maus:

Please show the content of the file |/var/tmp/cgimail.XXXX| if this happens again

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jens-maus/RaspberryMatic/issues/150#issuecomment-326667085, or mute the thread https://github.com/notifications/unsubscribe-auth/AFjdM2lYVcwj-CcgTyMoEjMCV9zgOBt_ks5seF0EgaJpZM4PKiE-.

[jens-maus]

Welche datei jetzt? Dort muss (wenn der fehler auftritt) eiwn datei liegen die mit "cgimail" beginnt.

Bitte auch hier nicht per email antworten sondern github verwenden.

[henrydiesner]

Im Pfad /var/tmp/ gibt es leider keine Datei "cgimail.xxxx". Die einzige Datei in diesem Ordner ist im Anhang. Glücklicherweise hatte ein neuer Versuch, ein Backup zu erstellen Erfolg. api_ipc.zip

[jens-maus]

Das macht ja auch sinn. Die datei existiert nur wenn dss backup mit dieser meldung fehl schlägt.

[jens-maus]

4558ccb49cd6efc3d846cb2f4b6685f823e4fcfc should fix/workaround this problem for the time being.

[Damian411]

Same symptoms here with version 2.29.22.20170902. File "cgimail.xxxx" does not exists, but every time an entry in dmesg:

[ 3147.206776] VFS: Lookup of '.' in ext4 mmcblk0p3 would have caused loop
[ 3195.956591] VFS: Lookup of '.' in ext4 mmcblk0p3 would have caused loop
[ 3380.555874] VFS: Lookup of '.' in ext4 mmcblk0p3 would have caused loop
[ 3418.441620] VFS: Lookup of '.' in ext4 mmcblk0p3 would have caused loop

# cd /var/tmp/
# ls -l
total 4
-rw-r--r--    1 root     root           273 Sep 27 20:38 api_ipc.cache

[jens-maus]

@Damian411 Please show the output of df -h. And which CCU Addons have you installed?

[Damian411]

# df -h                                                 
Filesystem                Size      Used Available Use% 
Mounted on                                              
/dev/root               476.2M    310.7M    136.5M  69%  /                                                       
devtmpfs                459.2M         0    459.2M   0%  /dev                                                    
tmpfs                   463.7M         0    463.7M   0%  /dev/shm                                                
tmpfs                   463.7M    104.0K    463.6M   0% /tmp                                                    
tmpfs                   463.7M     76.0K    463.6M   0%  /run                                                    
tmpfs                   463.7M    360.0K    463.3M   0% /var                                                    
tmpfs                   463.7M         0    463.7M   0% /media                                                  
/dev/mmcblk0p3           14.1G     50.7M     13.3G   0% /usr/local                                              
/dev/mmcblk0p1           31.9M      7.2M     24.7M  23% /boot

[Damian411]

CuxD and XML-API from the Github RassberryMatic Links. It is a fresh System installed some days ago.

[jens-maus]

@Damian411 Thanks, and the VFS: Lookup Error is really correlated with starting a backup via WebUI?

[jens-maus]

Are you trying to mount anything (e.g. NFS drive) via CUxD?

[Damian411]

No, I use XML-API for the App Homedroid and CuxD for Pushsafer

[Damian411]

And yes, every time I click on "Backup erstellen" the message occurs

[illestefan]

Hi Jens and Damian, same problem here. Suddenly I cannot create backups any more. Same message: "An internal error was detected in the service software. The diagnostics are being emailed to the service system administrator (root)." but no file cgimailxxx in /var/tmp df -h looks exactly as Damians. I did not change anything on my system. Just wanted to create a backup for installation of the latest firmware... How can I help with further information, Jens?

[jens-maus]

@illestefan Do you also get these VFS messages when you enter dmesg on the command line?

[illestefan]

No, Jens. dmesg is totally inconspicuous in my case..

[Damian411]

Is there something like a debug mode for the backup process?

[jens-maus]

@illestefan Strange that you don‘t get a cgimail file, this should be the case, normally. Currently I don‘t have any idea what is going on at your installation.

@Damian411 Not really. But you can use the /bin/createBackup.sh script to create a backup file and store it locally (e.g. in /usr/local/tmp). This should work at all times.

[illestefan]

Jens,

I found the mail file in /usr/local/tmp instead of /var/tmp. And it shows clearly what happened:

CGI environment:
REQUEST_METHOD: GET
SCRIPT_NAME: /config/cp_security.cgi
HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
HTTP_REFERER: http://192.168.178.54/pages/index.htm?sid=xxx@&client=3
HTTP_HOST: 192.168.178.54
REMOTE_ADDR: 192.168.178.230
cgi.tcl version: 1.8.0
input:
sid=xxx&action=create_backup
cookie:
errorInfo:
tar: usr/local/sdcard/ccu-historian/history.h2.db: file changed as we read it
    while executing
"exec tar --exclude=usr/local/tmp --exclude=usr/local/lost+found -czf $tmpdir/usr_local.tar.gz usr/local"
    (procedure "action_create_backup" line 11)
    invoked from within
"action_create_backup"
    invoked from within
"if {[session_requestisvalid 8] > 0} then action_$action"

the problem is that the ccu historian database changed during backup. Seems to be similar to the problem you mentiond in https://github.com/jens-maus/RaspberryMatic/commit/4558ccb49cd6efc3d846cb2f4b6685f823e4fcfc

Greets Stefan

[jens-maus]

@illestefan An now tell me which RaspberryMatic version you are running?

@Damian411 Please also have a look in /usr/local/tmp for the cgimail file and report its content here.

[jens-maus]

@illestefan After short investigation, I am almost sure you are NOT using the latest 2.29.22.20170902 release despite the fact that this version should fix these issues (see https://github.com/jens-maus/RaspberryMatic/commit/746018cfe65fced3b79cd90c307ee7634ea9a225). So please, next time check the latest version first before you report any problems.

[illestefan]

Of course you are right. I wanted to install exactly this version and therefore I tried to create a backup... But... it didn't work... So what should I have done? The file path for the cgimailxxx-file was not the right one and that I could start a backup manually was only mentioned here during our discussion. Sorry for bothering you.

[jens-maus]

@illestefan You should have asked the Homematic Forum and not the bugtracker here. Now disable CCU-Historian, create the Backup and upgrade ;)

[illestefan]

Sorry again :-(

[Damian411]

The backup with "/bin/createBackup.sh" works, thanks!

Here my version: Aktuelle Firmwareversion: | 2.29.22.20170902

Here the content of cgi file:

# more /usr/local/tmp/cgimail.1410
Return-Path: <CGI script - do not reply>
From:  <CGI script - do not reply>
To: root
Subject:  CGI problem

CGI environment:
REQUEST_METHOD: GET
SCRIPT_NAME: /config/cp_security.cgi
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
HTTP_REFERER: http://192.168.1.111/pages/index.htm?sid=@W3yzp7DWMy@
HTTP_HOST: 192.168.1.111
REMOTE_ADDR: 192.168.1.55
cgi.tcl version: 1.8.0
input:
sid=@W3yzp7DWMy@&action=create_backup
cookie:
errorInfo:
tar: usr/local/etc/config/eshlight/ma\360db: File removed before we read it
tar: usr/local/etc/config/eshlight/\016.: Warning: Cannot stat: Too many levels of symbolic links
    while executing
"exec tar --owner=root --group=root --exclude=usr/local/tmp --exclude=usr/local/lost+found --one-file-system --ignore-failed-read -czf $tmpdir/usr_loca..."
    (procedure "action_create_backup" line 11)
    invoked from within
"action_create_backup"
    invoked from within
"if {[session_requestisvalid 8] > 0} then action_$action"

And this is also interesting:

# cd /usr/local/etc/config/eshlight/
# ls -l
ls: ./ma▒db: No such file or directory
ls: ./.: Too many levels of symbolic links
total 4
drwxr-xr-x    2 root     root          4096 Sep 27 17:25 mapdb
#

[jens-maus]

@Damian411 Oh, this actually doesn't look good. Do you have any OSRAM lightify lights connected to your CCU/RaspberryMatic? If not, you could try to remove the whole /usr/local/etc/config/eshlight directory and recreate it empty. Still the question remains how these files were ending up with such strange filenames. To me this either looks like the SD card is somehow problematic or your filesystem is partly corrupt. IMHO you should use /usr/bin/createBackup.sh to create the backup, download it and recreate your RaspberryMatic on a fresh, new SD card and restoring this backup afterwards.

[Damian411]

Removing and create the folder has solved the issue. But I will swap the SD card with a new one. Thank you Jens.

[illestefan]

Just a last comment: I did as recommended. I stopped ccu-historian, created a backup (worked as you expected), installed the 2.29.22.20170902 on a fresh sd-card, rebooted the system and restored the backup. All fine. System up and working. Until i tried to create a backup. Should have worked now, right? But it didn't. Exactly the same error as before. So your fix does not work:

cat cgimail.1173 
Return-Path: <CGI script - do not reply>
From:  <CGI script - do not reply>
To: root
Subject:  CGI problem

CGI environment:
REQUEST_METHOD: GET
SCRIPT_NAME: /config/cp_security.cgi
HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
HTTP_REFERER: http://192.168.178.54/pages/index.htm?sid=yyy&client=3
HTTP_HOST: 192.168.178.54
REMOTE_ADDR: 192.168.178.230
cgi.tcl version: 1.8.0
input:
sid=yyy&action=create_backup
cookie:
errorInfo:
tar: usr/local/sdcard/ccu-historian/history.h2.db: file changed as we read it
    while executing
"exec tar --owner=root --group=root --exclude=usr/local/tmp --exclude=usr/local/lost+found --one-file-system --ignore-failed-read -czf $tmpdir/usr_loca..."
    (procedure "action_create_backup" line 11)
    invoked from within
"action_create_backup"
    invoked from within
"if {[session_requestisvalid 8] > 0} then action_$action"
# 

[jens-maus]

Please try to add 2>/dev/null to the corresponding tar execution line in the co_security.cgi file. This should hopefully finally solve the issue. See https://github.com/jens-maus/RaspberryMatic/commit/0a2b7cca0c1484029e9a893fafeb230e7e6d8ca8

[illestefan]

did not help. Now I am getting this:

cat /usr/local/tmp/cgimail.3021 
Return-Path: <CGI script - do not reply>
From:  <CGI script - do not reply>
To: root
Subject:  CGI problem

CGI environment:
REQUEST_METHOD: GET
SCRIPT_NAME: /config/cp_security.cgi
HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
HTTP_REFERER: http://192.168.178.54/pages/index.htm?sid=zzz&client=3
HTTP_HOST: 192.168.178.54
REMOTE_ADDR: 192.168.178.230
cgi.tcl version: 1.8.0
input:
sid=@zzz&action=create_backup
cookie:
errorInfo:
child process exited abnormally
    while executing
"exec tar --owner=root --group=root --exclude=usr/local/tmp --exclude=usr/local/lost+found --one-file-system --ignore-failed-read -czf $tmpdir/usr_loca..."
    (procedure "action_create_backup" line 11)
    invoked from within
"action_create_backup"
    invoked from within
"if {[session_requestisvalid 8] > 0} then action_$action"

[jens-maus]

@illestefan Thanks. Then please try to enclose the exec tar .... in a catch {...} statements like in https://github.com/jens-maus/RaspberryMatic/commit/4558ccb49cd6efc3d846cb2f4b6685f823e4fcfc perhaps this will solve it.

[illestefan]

That worked, Jens. Thank you.

[jens-maus]

Ok great, then please try it again, but remove the 2>/dev/null again so that I can seenof that has any effect. Thanks.

[illestefan]

Ok. I can confirm that the catch{} alone is sufficient. It works without the error redirection to /dev/null