<div dir="ltr">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@alethkar systemctl start myserver@frostlands systemctl start myserver@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.

</div>