Sorry your message appears to cut off the error message?
That seems to be an error message/code from emonhub.py What does an error code of 2 mean?
Hmm. If I type /usr/bin/env python junk.py I get [Errno 2] No such file or directory. Is that what it means? In any case I think it’s pointing to a problem with the executable or its parameters, not with systemd or the service file. (I think as in that’s my SWAG)
Sorry its:
May 27 17:38:32 emonpi systemd[1]: emonhub.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
The full line that I have here is:
ExecStart=/usr/bin/env python $EMONHUB_SRC/emonhub.py --config-file=/home/pi/data/emonhub.conf --logfile=/var/log/emonhub/emonhub.
and I’ve tested:
ExecStart=/usr/bin/python $EMONHUB_SRC/emonhub.py --config-file=/home/pi/data/emonhub.conf --logfile=/var/log/emonhub/emonhub.logDid you try echo or /bin/echo?
or what about
ExecStart=/bin/bash -c 'echo ${EMONHUB_SRC}/emonhub.py --config-file=/home/pi/data/emonhub.conf --logfile=/var/log/emonhub/emonhub.log`
take a look at the “COMMAND LINES” section in man systemd.service (or there’s a copy at systemd.service).
Thanks @pb66
ExecStart=echo ${EMONHUB_SRC}/emonhub.py --config-file=/home/pi/data/emonhub.conf --logfile=/var/log$
gives me:
Failed to start emonhub.service: Unit emonhub.service is not loaded properly: Invalid argument.
See system logs and 'systemctl status emonhub.service' for details.
the second also fails unfortunately.
@pb66, what’s the point of the echo commands?
@TrystanLea , what’s in the system logs and the systemsctl status then?
But in reply to the status=2/INVALIDARGUMENT I still believe that is a message from emonhub.py
I’d try myself but I don’t have a test system and haven’t thought of any suitably innocuous python program I could use.
edit: Does /var/log/emonhub/emonhub.log or the directory exist?
Im not sure why, but after starting from scratch the following is now working:
[Service]
EnvironmentFile=/home/pi/emonhub.env
User=emonhub
PIDFile=/var/run/emonhub.pid
ExecStart=/usr/bin/python ${EMONHUB_SRC}/emonhub.py --config-file=/home/pi/data/emonhub.conf --logfile=/var/log/emonhub/emonhub.log
That’s good news. It would be nice to understand what the problem was, but at least it’s progress.
Yes, its a bit strange, must have been a missing character or something…
This as a full line for the conf and log also works, with associated entries in emonhub.env:
ExecStart=/usr/bin/python ${EMONHUB_SRC}/emonhub.py --config-file=${EMONHUB_CONF}/emonhub.conf --logfile=${EMONHUB_LOG}/emonhub.log@djh it might be good to provide default paths in the service file and only overwrite them if the env file exists. I can set the default paths using Environment=‘EMONHUB_SRC=/opt/emon/emonhub’ but Im not sure if there is a way to only try loading the environment file if it exists? If I try and delete the env file the service fails to start as you might expect.
I’m not sure that’s such a good idea. It just adds another complication - another case to understand. What’s the benefit?
I was just thinking that it could default back to the most standard paths if the env file was not present. But not to worry.
So it looks like this approach could work, perhaps emonhub.env could be placed in /etc/emonhub alongside emonhub.conf and we make the choice to fix that particular path.
I’ve pushed these changes to a branch called env_example here: https://github.com/openenergymonitor/emonhub/compare/env_example
Taking a step back, we have this option or we have the symlink to /usr/local/bin approach.
The installation process for the env file approach involves the installation script copying the emonhub.env file to /etc/emonhub/emonhub.env and then editing the emonhub install path to the relevant location.
The installation process for the symlink approach is simpler, it only requires a single symlink e.g: https://github.com/openenergymonitor/emonhub/blob/emon-pi/install.sh#L64
Im a bit on the fence with this one, I dont see /usr/local/bin as being the location users might go and look for the source but I do like its slightly simpler installation process.
@pb66 @borpin what do you both think of the env approach now that we have a working example?
I think you’re oversimplifying, or overcomplicating or perhaps not looking at the whole problem. The installation in general cannot be done by the program itself, only in the special case that everything is in the standard/default place. It requires a human to edit the .env file in general. So the installer doesn’t need to edit the file, just copy it. Changes are up to the person running it.
For example, if I wanted to move the log somewhere else, the installer would have no way of knowing that and couldn’t edit the file for me. The only thing it can know is its own location and there’s no value in making that an exception IMHO.
BTW, the symlink to /usr/share is not something I would allow on my machine. That’s a distro-only directory so I’d want to change it to something else. The installer would fail anyway unless it was running as root.
Also, /var/run is deprecated. It’s just /run these days.
No, but the effect is the same. /usr/local is a place for the local administrator to install stuff for all users of the machine. It isn’t supposed to be used by packages though.
It’s worth reading section 3.13 of the FHS, about /opt. As well as saying where add-on application packages should put files, it also says where they may NOT put files, which basically covers everywhere else, with a very few exceptions. So it explicitly says that an add-on package can provide a file that is intended to be symlinked to /opt/bin for example but must leave it up to the administrator to make such a link. /usr/local doesn’t even get that privilege, it comes under the general exclusion.
Thanks @djh that seems pretty conclusive.
I will wait for @pb66 and @borpin to respond and then assuming we are all happy with this, move forward with the .env approach
Not unhappy.
.gitignore is so it isn’t changed if the user edits it? use a ‘default’ that needs to be copied to the .env?I’m really not sure whats being proposed!
The use of EnvironmentFile to change the paths in the service units is certainly a potential alternative to using systemctl edit, either is far better than writing the service units into place (whilst using a cloned source to update the project).
This doesn’t seem to address whether symlinks are still used and/or what paths will be used. Will there be a single env file or multiple? What the rational behind that answer? Where will this file(s) reside? Is that configurable? Is it symlinked, written into place or fully detached and maintained by the user? I’m not against exploring further.
Maybe env variables could be set up in the admin module
On the heroku dashboard, there is a specific controller which can be used to adjust env parameters…the heroku guys used to call them the config vars…
Anyway I’ve tested the new scripts
Nice job…working fine on Ubuntu, still could not make them work on a dietPI…
I don’t understand the point? The environment variables set the paths to the executables and other things. If they aren’t already set, the system won’t run and there won’t be an admin interface. Changing them on a running system would break the system.
[edit]: note that config variables are something different; changing behaviour etc.
What version of DietPi and did you do any installs by dietpi-software? I don’t expect these to work out of the box for DietPi as it does some weird and wonderful things in the background. Biggest issue right now is their LAMP/LLMP stack installs PHP7.3.
