Symlinking services in Jessie doesn't work

[Bill.Thomson]

@Greebo

If you ditch that line, or change it to Type=exec does the error about the lvalue go away?

No, it gives me the error either way, i.e. whether the line is there or not.

@borpin

Odd, cannot see why it should complain unless there is the same unit in the search path somewhere perhaps?

Made sure that didn’t happen.

[Greebo]

@Bill.Thomson

No, it gives me the error either way, i.e. whether the line is there or not.

@Bill.Thomson

The error message it gave me was:
[/lib/systemd/system/hplt-pwr.service:6] Unknown lvalue 'type' in section 'Service'

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!

[Bill.Thomson]

Same error.
The weird part is when I move the file to the /etc/systemd/system directory the error goes away.

[Greebo]

Ok, can you clarify exactly what you’ve done after you put the file in /lib/systemd/system?

[Bill.Thomson]

In /lib… or /etc… ?

[Greebo]

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?

[andy_l (Andy)]

@borpin

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 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.

@borpin

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.

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.

[Bill.Thomson]

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.

[andy_l (Andy)]

@Greebo

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…

Aha! Thanks Greebo. Reading through that PR fills in all the gaps and confirms the behaviour I’ve been seeing.

Slightly frustrating though, because the Pull Request recommendation to have ‘special instructions’ for Jessie users never actually made it to the service install notes - if they had, we wouldn’t have this thread

Thanks again,

Andy

[Greebo]

@Bill.Thomson

Enabled it, then checked the status to see if it was running.

Do you mean you ran the following?

sudo systemctl enable hplt-pwr
systemctl status hplt-pwr

If so, after doing that is there a symlink in /etc/systemd/system pointing to the file in /lib/systemd/system?

[Bill.Thomson]

Yes, those are the commands I ran. (with sudo prefixed to the status command as well)
It put the symlink in /etc/systemd/system/multi-user.target.wants/

[Greebo]

Can you post the full output of the status command when the file is in /lib/systemd/system?

[Bill.Thomson]

Since it’s working, I’m thinking it’s best not to mess with it.
I sure as heck didn’t mean to hijack the thread. That wasn’t intended.
I’m going to let it ride as is.

Thanks for taking time to troubleshoot it.