[NBLUG/talk] Recap of systemd talk, and other thoughts?

Lincoln Peters anfrind at gmail.com
Fri Jun 12 11:03:43 PDT 2015


I've been dealing with systemd at work for the past several weeks, but I
was unable to attend the meeting on Tuesday. Any highlights from the
meeting that anyone wants to share?

My own experience has been that on one hand, systemd has a lot of good
ideas that make it much easier to define and manage system services--I work
on a product that installs three services on a RHEL or CentOS server, and
once I figured out what I was doing, I was able to define the first two
with a pair of trivial .service files. On the other hand, there do seem to
be a number of odd quirks, and some behaviors that appear to be outright
bugs. For example, I had set the first service to require omniORB (the
services talk to each other via CORBA), and didn't realize that restarting
omniORB would also cause my service to restart (which is not what I
wanted).  I was able to work around that by changing the parameter from
"Requires" to "After" (i.e. start after omniORB but don't require that
omniORB is actually running), but I don't recall seeing anything in the
documentation indicating that it would do that.

The biggest problem I ran into was with our third service.  The original
initscript was kind of weird (and admittedly breaks a few LSB conventions),
and could instantiate multiple servers depending on how many different
configurations the user wanted it to run in (no upper limit to how many
servers in different configurations can be run). I realized that it would
probably be easier to deal with this service in systemd by using a
parameterized service, which would allow each instance to be managed
individually (something we couldn't do before). However, it took a lot of
digging to figure out how to set up a target so that we could start and
stop all of the desired servers simultaneously (I had to write a separate
script that manages "wants" relationships between server instances and the
target), and I found that systemd has rules for "escaping" service names
that are kind of weird (at least in the version shipped with CentOS 7.0).
In our case, the parameter is passed through to the start script as a
command-line argument, and if, for example, I issue the following commands:

systemctl start myserver at alethkar
systemctl start myserver at frostlands
systemctl start myserver at jah-keved

The first two instances start as expected, but the third fails because
systemd escapes the parameter to "jah\-keved"* before passing it to my
script, no matter if I use %i (escaped instance name) or %I (unescaped
instance name) in my .service file, which would seem to contradict what the
documentation says. As you might expect, when my start script sees the
"escaped" parameter, it gets confused and does the wrong thing. I may need
to modify my start script to un-escape the parameter itself in order to
make it work.

Anyone else have thoughts to share about systemd?

* I don't have access to a system with this service file while writing this
e-mail, so the escaped string is from memory and might be wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nblug.org/pipermail/talk/attachments/20150612/46053783/attachment.html>


More information about the talk mailing list