More systemd friendly?

[mdavidsaver]

A half-baked idea for how to make procServ, with its long argument lists, friendlier for use with systemd. Since systemd does not expand environment variables in ExecStart=, teach procServ to do so.

eg. /etc/systemd/system/procServ@.service

Environment="PROCCMD=false"
ExecStart=/usr/bin/procServ -f  ... $PROCCMD

This allows a unit override file to change only $PROCCMD without needing to repeat the whole long ExecStart=.

eg. /etc/systemd/system/procServ@foo.service/override.conf

Environment="PROCCMD=./st.cmd"
WorkingDirectory=/iocs/foo
User=softioc
Group=softioc

Would be a more concise expression of what, where, and who.

I'm not sure what the semantics would be to handle command arguments. As written, this PR expands one environment variable as one argument. eg PROCCMD=foo bar would exec "foo bar" instead of exec "foo" "bar" as might be expected.

Maybe a better way would be to do indirection for procServ argument values, and add a new argument for the un-split command? eg.

procServ -P $PORT --cmd $PROCCMD

[anjohnson]

Feels yucky.

This is partly why we use Makefiles to generate systemd.unit files from templates, using envsubst to expand them.

[anjohnson]

The documentation for this needs to point out that it only accepts environment variables as a complete argument. As implemented an argument can't have a variable somewhere in the middle.

[mdavidsaver]

If there is enough interest, I would implement shell style unquoting and argument splitting.

[mdavidsaver]

This is partly why we use Makefiles to generate systemd.unit

I have seen (and been responsible for) several variations on this theme. Not least the procServUtils/ scripts in this repository. I am not enthused about any of them. imo. They are at best unit files in a different format, and more typically a filter limiting the systemd features to those available at the time they are created. (I include procServUtils/ in this statement)

Still, this PR would not make these scripts go away. Only to reduce the content emitted to shorter override.conf files, which would also be more amiable to manual creation. Leaving much of the boilerplate in the base procServ@.service. Which effectively becomes your template.

[mdavidsaver]

Another idea. Using ExecStartPre= to dynamically generate a launcher script in a temporary location.

[ralphlange]

Another idea. Using ExecStartPre= to dynamically generate a launcher script in a temporary location.

Oh my. That sounds like the next generation of the CA Gateway's killer and restart scripts... (It's a one-off and considerably different, I know.)

To be honest, I'd rather go (same for the Gateway, btw.) for a configuration file containing option=<value> lines in [section] blocks. Easy to understand, well covered with Ansible rules, takes these things out of the systemd game.

One could find a generic C++ class that works for both procServ and the Gateway.
I would also try to outsource compatibility: check for the --config parameter and - if missing - call a script that converts the complete command line into a temporary config file.