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ā¦
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.
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 /lib/systemd/system/. Modifications done by system administrator (user) should be in /etc/systemd/system/
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 enable mechanism.
Modifications done by system administrator (user) should be in /etc/systemd/system/
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.
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 /etc/systemd/system/ folder.
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ā¦
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 systemd v236.
Interestingly, the error says type but your post has Type - are you sure the service file is in Sentence case as you posted it?
It is hence recommended not to needlessly use any types other than simple . (Also note it is generally not recommended to use idle or oneshot for long-running services.)
ā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?
