systemd fails to substitute environment variables on startup

[Chinasaur]

I have two custom service unit descriptions that are enabled to run on startup. Both of them have EnvironmentFile definitions that point to /etc/servicename.env and include a handful of variable assignments. Both of them work fine when run from `systemctl start`. One of them runs fine on startup after `systemctl enable`, but the other doesn't.

Here's what `systemctl status` tells me about the failed service:
$this->bbcode_second_pass_code('', 'wsgw.service - WebSockets Gateway for pianod
Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled)
Active: inactive (dead) since Wed 1969-12-31 16:00:08 PST; 43 years 2 months ago
Process: 131 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES (code=exited, status=0/SUCCESS)')

So apparently the service fails because the ExecStart line still has these dorky variable strings instead of the proper substitutions. I diffed the /etc/systemd and /usr/lib/systemd versions of the service unit description and they're the same. When I then run `systemctl start` with the same service unit, it works and the status line shows the proper variable substitutions. What's going wrong?

Thanks in advance.

[pepedog]

You put the file in /etc/systemd/system then you
systemctl reenable wsgw
You should see symlink created, it will start on boot
systemctl start wsgw
if you want it to start now

[Chinasaur]

Well, I already have the symlinks from `systemctl enable`, and I already know that it works with `systemctl start`. I've tried disabling and then enabling again, which I assume is the same as running reenable. The problem is that on boot, what gets run from the symlink doesn't have the variables substituted properly, whereas when run from `systemctl start` after boot it does. But this is only for this one unit description, whereas the other service I wrote with essentially the same layout works fine.

[pepedog]

So you didn't try what I suggested, reenable an all?

[Chinasaur]

From the man page: "Reenable one or more unit files, as specified on the command line. This is a combination of disable and enable..." I have tried disable and enable.

But if you insist, I will try reenable and report back. The machine is not accessible to me at all hours, so I cannot try every suggestion immediately. Edit: as expected, no change after reenable.

Thanks for your replies, but in my opinion a more careful reading of my problem description is in order.

[pepedog]

Well you said "I diffed the /etc/systemd and /usr/lib/systemd versions " and /etc/systemd is the wrong place for custom
If you put it in /etc/systemd/system and reenable, it symlinks to version in /etc/systemd/system

Perhaps we best see service files, and where they are located
https://wiki.archlinux.org/index.php/SystemD#Editing_provided_unit_files

[Chinasaur]

What I meant is that I diffed the version in the multi-user target wants directory to check whether anything funny happened to the file when it was copied from /usr/lib/systemd/system/. I forgot that it is a symlink and not a copy, so it was a pointless thing to check. Sorry for the confusion.

Unfortunately I won't have access to the system for the next week, but I'll try to explain in more detail as best I can. I wrote these two unit files and installed them to /usr/lib/systemd/system/. They are very simple and structured the same way:
http://svn.deviousfish.com/pianod/piano ... od.service
http://svn.deviousfish.com/wsgw/contrib/wsgw.service

The environment files are like this:
http://svn.deviousfish.com/pianod/piano ... pianod.env
http://svn.deviousfish.com/wsgw/contrib/wsgw.env

I'm sorry I skipped these details in my original question, but due to behavior I'm seeing my feeling was (and still is) that the basic setup is correct. Both of these services start, stop, and report status fine. The pianod service also starts on boot fine after `systemctl enable pianod`, but with the wsgw service it fails to run on boot after being enabled.

The nature of the failure seems to be that the environment variables are left unsubstituted, as noted in the original post. I base this on the `systemctl status wsgw` output. After running `systemctl start wsgw` and then `systemctl status wsgw`, the command is shown with proper variable substitution. But after a boot, when the service has failed to start, `systemctl status wsgw` outputs as above, with the variables unsubstituted.

Occurs to me I should check all the permissions, but doesn't seem like that should be the issue. Any other thoughts?

[pepedog]

I think you need quotes, especially if there is a space
PORT=-p 8000
becomes
PORT="-p 8000"

If you need (which you don't) an array, you use brackets
ie, you intend to do this for 1, then 2, then 3
PARAMDO=("1" "2" "3")

[Chinasaur]

Good idea, but it seems to me that the fact that the whole thing works with `systemctl start wsgw` means that the quotes should not be the problem?

[Chinasaur]

I tried adding quotes, but it didn't change the behavior.

Just to be totally clear, in the cases where the service runs in the background successfully, if I do `systemctl status wsgw` or `systemctl status pianod` I see the variables have already been substituted on the ExecStart= line of the status report.