@TrystanLea, trying to update my Emonscripts ubuntu installation but it fails. As I don’t know what is being called when (the log doesn’t say what is being called, I can’t easily debug it.
Can you confirm the process the ‘update’ takes please?
Starting update via service-runner-update.sh (v3.0) >
- Could not find emonSD version file
git pull /opt/openenergymonitor/EmonScripts
* master
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
install/config.ini.bak
nothing added to commit but untracked files present (use "git add" to track)
From https://github.com/openenergymonitor/EmonScripts
b804e32..b255689 master -> origin/master
Updating b804e32..b255689
Fast-forward
defaults/emoncms/emonpi.settings.ini | 27 +++++++++++++++++++++++++++
install/emoncms_core.sh | 14 +++++++-------
2 files changed, 34 insertions(+), 7 deletions(-)
create mode 100644 defaults/emoncms/emonpi.settings.ini
-------------------------------------------------------------
Main Update Script
-------------------------------------------------------------
Date: Wed Sep 25 17:50:59 UTC 2019
EUID: 0
openenergymonitor_dir: /opt/openenergymonitor
type: emoncms
firmware: emonpi
update running as root, switch to user
Im not sure that it has failed, there’s an old bak file that’s causing that notice but it may not be getting in the way. It should be safe to delete config.ini.bak
In the first case (above) it was running as root (no user specified) as per the documentation. I think I suggested this for my DietPi install.
In the second case, it was running as a non root user who is a member of sudo(need to install that on Ubuntu) - Getting confused with a Debian install I tried.
Yes I have - I have a theory but I’ve not got time tonight to play and I’m away for a few days.
The folder /var/log/emoncms/ is root:root. This might be because of me running all the services as root. I’ll have to reinstall and see.
If the service install script could automatically create a drop-in that creates the user as set in the script, that might just solve it all! - It might not of course!
The other approach is to create an emon user as discussed elsewhere so the services always run as that. Would solve some of the multi platform issues, but might introduce others .