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 /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…
2 Likes
Can you share that section of your service file… I have a hunch 
You bet. Here it is:
[Service]
Type=idle
ExecStart=/usr/bin/python /home/bt/wattson.py
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 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?
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 useidleoroneshotfor 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.
1 Like
“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?
No, it gives me the error either way, i.e. whether the line is there or not.
Made sure that didn’t happen.
1 Like
That exact same error, or a different lvalue error? If you’re getting that error without the Type= line, something else is definitely going on!
Same error.
The weird part is when I move the file to the /etc/systemd/system directory the error goes away.
Ok, can you clarify exactly what you’ve done after you put the file in /lib/systemd/system?
In /lib… or /etc… ?
The issue of the lvalue error occurs when you put the service unit into /lib right? If so, then what did you do after you put the file in there?
I do use emonBase, but funnily enough I upgraded to the RFM69 receiver board because I wanted RSSI values. Good to know about the emonSD behaviour though.
It’s not just about the base. For instance, the emonHub node decoder assumes your nodes conform to a particular ID range set by DIP switches, whereas mine do not. Other things like firmware have been forgotten about; for example the only emonTH 1.x firmware in Git is for 1.5 boards, as it includes JeeLib and all of the DIP switch logic. As this last version of firmware was the most optimised, I have ‘ported’ it back to my 1.4 boards by reverting to RFu_JeeLib and pulling out the DIP switch logic, but it’s yet another ‘non-standard’ part.
So really it’s about the system as a whole and the amount of tweaks that become necessary during major emoncms releases.
Anyways, appreciate your advice - thanks.
Enabled it, then checked the status to see if it was running.
It was running, but that’s when I noticed the error. Didn’t do anything else.