Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Problem with Export/Backup script: emoncms-export.sh

@TrystanLea

I’m running the Oct 2019 image updated to ver 10.2.6.

For the first time after very many uses, I had a problem running this script. From an SSH terminal:


=== Emoncms export start ===

Mon 28 Dec 17:56:19 GMT 2020

Backup module version:

"version" : "2.2.6"

EUID: 1000

Reading ./config.cfg....

Location of databases: /var/opt/emoncms

Location of emonhub.conf: /etc/emonhub

Location of Emoncms: /var/www/emoncms

Backup destination: /var/opt/emoncms/backup

emoncms backup module location /var/www/emoncms/Modules/backup

Image version: emonSD-17Oct19

**Failed to stop feedwriter.service: Connection timed out**

See system logs and 'systemctl status feedwriter.service' for details.

Despite the fact that feedwriter was not stopped, the script continued with:


adding /var/opt/emoncms/backup/emoncms.sql to archive --

*Then later:*

phptimeseries/feed_16.MYD

tar: phptimeseries/feed_16.MYD: file changed as we read it

*Then later:*

phptimeseries/feed_55.MYD

Error: failed to tar phptimeseries

The Export/Backup finished but clearly it was flawed.

I then checked the feedwriter.service status. It was running and it stopped and restarted without problem. I then re-ran the Export/Backup script without any problem.

Looking at the script in detail, I wonder whether it might be cautiously smart to move lines 62 & 63 to earlier before any deletions are made. If feedwriter fails to stop then the script could exit and the user be prompted to try again.


# Disabled in @borphin commit?

sudo service feedwriter stop

Just my thoughts

I think the deletions are just housekeeping rather than anything significant.

I wonder if these commands should be updated to use systemctl.

Did you use service or systemctl?

Might be coincidence, but I just had reason to stop one of my emonhub instances (this is just emonhub not an EmonSD) and it took an age to deactivate. It had been running for over 2 months.

@borpin
I used systemctl
And it looks like that is now the preferred alternative …
Should the Export/Backup script be updated?

It has been the preferred command for a while.

Probably yes the script(s) should be updated.

Did it fail that once or is it doing it regularly? If regularly you could modify it locally and see if that fixes the issue.

@borpin
It has only failed once as far as I’m aware - was running it in an SSH terminal.
BUT normally my backups run weekly via a cronjob and so I would have been blissfully unaware of any earlier failures.

I’ve updated the master branch of the backup module to use systemctl, here are all the changes https://github.com/emoncms/backup/commit/e58dd8fea3a8e44d475725e8f98a7145eea2ab08 do you think you could test this version before I merge to stable @johnbanks @borpin?

Testing the export works fine for me at least.

@TrystanLea
I’m happy to test the export option.
But github is a total mystery to me.
How do I download & install yr changes?
Thx

Hello @johnbanks sure, the step are:

cd /opt/emoncms/modules/backup
git checkout master

To switch back its:

cd /opt/emoncms/modules/backup
git checkout stable

Then

git pull
1 Like

@TrystanLea
I’m impressed.
It would not let me make the change to master until I’d removed a personalised version of usb-import.sh.
Having done that, it switched to master.
The new emoncm-export.sh ran OK.
I’ve not checked the other 3 scripts

That is Git for you.

If you wanted to preserve it, use

git stash

to get it back use

git stash pop

If you have a modified file, you will find git will never overwrite it (using git pull) so any update you do from the UI would not work. You always need to review the log after an update.