Whilst trying to keep my copy of Emoncms somewhere near current, I tried to install the new mqtt and service runner services. However it seems symlinking into /lib/systemd/system and then trying to enable the service does not work in Jessie, and results in:
Failed to execute operation: No such file or directory
Copying the service into /lib/systemd/system and then enabling does work, resulting in:
Created symlink from /etc/systemd/system/multi-user.target.wants/service-runner.service to /lib/systemd/system/service-runner.service
The internet is not much use on this topic - this does seem to have been a bug in systemd at some point but my Jessie installation is fully up-to-date. When the docs were written was this tested on Jessie, or just Stretch? I must admit that it’s getting harder to maintain a standalone (not pre-built) instance of Emoncms…
I think it is a ‘feature’ rather than a bug, that was added to later versions of systemd, which in themselves are not compatible with Jessie.
Just be warned, if you
disable the service, the files will be deleted and you will need to copy them across again.
If you are trying to do this on Jessie, then yes and it will be worth the effort to back it up and move it to a Stretch based system.
Do you have a specific reason for it being standalone? I effectively run EmonCMS standalone on a DietPi base OS in a VM without any real issues.
Thanks Brian, probably time to move to Stretch - maybe I’ll upgrade from Pi 2 to 3+ at the same time.
Habit I suppose… that and the fact I don’t have an emonPI. A lot has changed in the 5 years since I started using OpenEnergyMonitor, and the development into a proper product has left some of us in ‘non-standard’ configurations e.g. 868MHz radios, unusual node ID’s etc. Keeping a working ‘legacy’ configuration and staying near the dev curve seems to involve lots of tweaks each time.
C’est la vie!
Do you use the RFM ‘emonBase’ on the Pi? In which case take care with the EmonSD as it assumes you have one of the newer RFM modules and does an update on that basis (unless you tell it not to).
I was in a not too dissimilar position. A couple of years ago I bit the bullet and moved to a newer base. It was a pain but worth it in the end. The EmonSD is fine if that is all you do. I have other things setup so prefer to build from scratch (no MQTT broker for instance). I know I bang on about DietPi but I really am a fan. I wrote up a blog post on setting up EmonCMS on DietPi with Lighttpd as the base server.
I found that using the backup module (with a bit of modification for paths etc.) worked quite well the transfer to the new instance. (though I did run the 2 in parallel for a while
While browsing to learn more about systemd, I ran across this:
In brief, the takeaway is:
Files from distro packages should be in
Modifications done by system administrator (user) should be in
When I did a status check on a service script I wrote, I got an error about a bad lvalue in the [Service] section of the script. Double checking the script against other working scripts showed no typos, syntax errors, etc. (the script ran OK despite the status-check error)
The status-check error disappeared after I moved the script to /etc/systemd/system and re-enabled it. YMMV.
Systemd in Jessie is different to Stretch as @Greebo discovered!
BUT, if you
disable a unit all those modifications are deleted in
/etc/systemd/system/ as to disable a unit, systemd deletes the links or files if there in that location. Enabling a unit using systemd creates the links from files found in the search path so you effectively bypass the
Modifications done by system administrator (user) should be in
Personally I think that is poor advice by the link. Note also that was given in 2015 and systemd has changed since then. Generally advice is to change nothing in the
/etc/systemd/system/ folder except via the
systemctl edit command.
Was that on Jessie or Stretch?
As it would, but it is not robust solution.
There was a ton of discussion on the PR for
service-runner about systemd and service files and creating links.
It should work if the file goes in
/lib/systemd/system/ (or even a link as we now do for all the emoncms services), and you then
enable the service (if you want it to auto start).
The script did work when the file was in /lib/systemd/system.
But it gave me an error when the status was checked.
The script was enabled, and did start / run OK.
(as I mentioned above…)
Yes I go that. What I am saying is that it should work without error. What error did you get? You mentioned ‘bad lvalue’. Google did not throw anything up for that as an error message. It might have been caused by existing links or files.
I still stand by the advice not to do anything manually in the
As @borpin mentioned, I spent many hours poring over the man pages for the various
systemd components trying to work out why certain things did/didn’t work. Some things worked as per the man pages, other things didn’t and they weren’t consistent between jessie and stretch!
Turns out there are bugs and documentation changes between the various versions and the only way to be 100% sure you’re looking at the correct documentation for the actual version of systemd is to use
man from the system you’re playing on!
Much of the discussion happened in github and for various reasons there were numerous PR’s that ended up being submitted and the discussion spread over them. With that said, this one has the meat of it…
Can you share that section of your service file… I have a hunch
You bet. Here it is:
The error message it gave me was:
[/lib/systemd/system/hplt-pwr.service:6] Unknown lvalue 'type' in section 'Service'
Ok, that wasn’t my hunch! That’s the error I was getting when I used StandardOutput=file: and that was caused by the “file:” specifier only being available from
Interestingly, the error says
type but your post has
Type - are you sure the service file is in Sentence case as you posted it?
FWIW, the version release history of systemd can be found here: systemd/NEWS at main · systemd/systemd · GitHub
Just a thought - from the man page
It is hence recommended not to needlessly use any types other than
simple . (Also note it is generally not recommended to use
oneshot for long-running services.)
From the github page
Could it have been an old systemd version?
That was the first thing to catch my attention, hence the first thing I checked.
(I copy / pasted the [Service] section directly from the relevant file.)
I did a dist-upgrade on it only a few days ago, FWTW.
The version number is 232.
“stretch” has had systemd v232 since release, the only way to get a different version is to either do it yourself manually (build from source) or to include the stretch-backports repo (which will give you systemd v239)
I’m with @borpin though, seems using
Type=simple doen’t add any meaningful value anymore.
If you ditch that line, or change it to
Type=exec does the error about the
lvalue go away?
Odd, cannot see why it should complain unless there is the same unit in the search path somewhere perhaps?