Problems Installing Emoncms in Ubuntu 18.04


I have been trying to install emoncms in Ubuntu 18.04 following the information at EmonScripts/ at master · openenergymonitor/EmonScripts · GitHub but have a few problems.

When it get to doing Redis I get:

The directory '/home/g0lgs/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.

Then when it Starts Emoncms Core:

chown: invalid user: ‘pi’
fatal: could not create work tree dir 'emoncms': Permission denied
- creating emoncms log folder
mkdir: cannot create directory ‘/var/log/emoncms’: File exists
chown: invalid user: ‘pi’
- installing default emoncms settings.ini
cp: cannot create regular file '/var/www/emoncms/settings.ini': No such file or directory
sed: can't read /var/www/emoncms/settings.ini: No such file or directory
sed: can't read /var/www/emoncms/settings.ini: No such file or directory
sed: can't read /var/www/emoncms/settings.ini: No such file or directory
- datadir phpfina already exists
- datadir phpfiwa already exists
- datadir phptimeseries already exists
- symlinking emoncms folder to /var/www/html/emoncms
ln: failed to create symbolic link '/var/www/html/emoncms': File exists
- creating redirect to /var/www/emoncms
rm: cannot remove '/var/www/html/index.html': No such file or directory


Install Emoncms Core Modules
/opt/openenergymonitor/EmonScripts/install/ line 8: cd: /var/www/emoncms/Modules: No such file or directory
- Module app already exists
- Module graph already exists
- Module device already exists
- Module dashboard already exists
- Module usefulscripts already exists
- Module demandshaper already exists
- Module backup already exists
- Module postprocess already exists
- Module sync already exists
Update Emoncms database
PHP Warning:  chdir(): No such file or directory (errno 2) in /opt/openenergymonitor/EmonScripts/common/emoncmsdbupdate.php on line 8
PHP Warning:  require(process_settings.php): failed to open stream: No such file or directory in /opt/openenergymonitor/EmonScripts/common/emoncmsdbupdate.php on line 9
PHP Fatal error:  require(): Failed opening required 'process_settings.php' (include_path='.:/usr/share/php') in /opt/openenergymonitor/EmonScripts/common/emoncmsdbupdate.php on line 9

Are you logged in as the user ‘pi’?

Did you edit the config.ini to suit an Ubuntu Debian install? EmonScripts/ at master · openenergymonitor/EmonScripts · GitHub

I suspect you need to start again from scratch if you didn’t.

Well I’m now on the third attempt.

I missed that I needed to change the username in config.ini and with a bit of trial an error had to work out which other settings I needed to change (to remove things that only wortk on a pi).


Set the environment to not be a pi SD - can’t remember the exact setting.


Do I not need to set the following too?


As first time it tried to do each of those and had problems.

With unset (as you have), it should not try and install anything Pi specific.

Not trying to nit-pick… :wink:

but, emonSD_pi_env=0 is actually set.

if it were unset, the environment variable would go away vice being set to zero.



To me a 0 is false and 1 is true so the question “is this an emonSD pi Environment?” = False.

It isn’t really an ENV VAR. Set/Unset was probably the wrong phrase for the pedants here (mentioning no one in particular gunner2 ).

Alright for you Brian. :grin:

I looked through the script and found this line:

if { "$emonSD_pi_env = "1" ]; then

the operative clue there being the dollar sign, i.e. it’s an environment value, or more correctly,
an environment variable.

While it does indeed appear that I’m being pedantic, I mention it because there is a bash command called unset.

Back atcha, hammer_hitting_head

1 Like

So yes setting


Does indeed stop it installing pi specific things (as well as apparently disabling changing the hostname).

Anyway it solved my issue.


1 Like

The Pi is assumed to be a single use item and the scripts are used to build the prebuilt images. It does make sense that the hostname is not changed in a non-pi env - easy enough to do from the command line or do it when you create the initial server.

Great. Any suggestions for the docs so it is more obvious what to do?

You are an outlier using it on Ubuntu (I only have a test server setup), so any feedback on issues is welcome.

I am fine with the not chaging the hostname, but perhaps moving the


line down the config.ini a little and adding a comment that it only applies to pi could be useful.

Also making it a little more obvious that


Is required for non-pi Installs - i.e. a sample (commented out) version of the relevant settings for Debain/Ubuntu based installs.

I will also say that if installing on a pi then setting


Is not entirely sucessful as although the wifiap scripts are not installed /etc/rc.local still has the line in it that tries to start the WiFi AP.

Also disabling isc-dhcp-server from being auto-started (sudo systemctl disable isc-dhcp-server) might be worth doing too - as the WiFi AP script starts it when required - and it fails to auto start correctly if you have already configured WiFi or are using the Ethernet - see ‘sudo systemctl status -all’.

I may have a few other things to comment on at a later date (I’m currently working form home - looking at how we might use emonPi / emonTx devices at my place of work - so have been trying various things).

1 Like

It is the 3rd line comment :man_shrugging:


@TrystanLea couple of other comments for you.

Thanks for the feedback.

@G0LGS, did you start afresh with the server, or just delete and go again? The rc.local is not installed in a non-pi envionment neither is the WiFi check.

This file is not run

1 Like

It was refering to a fresh install:

As I said :

I don’t see what the quoted section refering to “install_emonsd” is about.

Looking at config.,ini again I think that some things could have better information as to what the options all do - especially for relative necomers (like me) to the ‘emonXXXX’ devices / software.

Perhaps even writing out a summary of what options are selected and what will or will not be installed before it actually starts.

Having run the install on a fresh new pi image this morning I found that the install appeared to be having trouble with some parts of the process and there were various messages about not being able to access the raspberry pi repo and not being able to run certain commands (pecl ?). It might be useful to have the script keep a log of what happened.

The end result was some things not working (feedwriter being one because ‘mysqli’ being undefined).

That isn’t a script issue. That is network / source repo issue - I’ve seen it before in other things.

yes I agree with this and have suggested it to @TrystanLea. I run the command as

./ 2>&1 | tee install.log

to create a log :grinning:.

Probably the thing to do is to create a reference document. Because the different parts are different scripts, listing everything before the start might be tricky.

1 Like