[systemd-devel] SysVInit service migration to systemd

[Jonathan de Boyne Pollard]

Lesley Kimmel:
> I've been working with RHEL5/6 for the past several years and have 
> developed many init scripts/services which generally use lock files 
> and PID files to allow for tracking of the service status. We are 
> moving to RHEL7 (systemd) in the near future and I am looking for 
> instruction or tutorials on how to effectively migrate these scripts 
> to work with systemd.   [...] It looks like I may be able to use the 
> 'forking' type with the 'pidfile' parameter to somewhat mimic what the 
> scripts to today.

You don't do such migration.  You understand how your daemons are 
started, and you write service (and other) units to describe that. You 
do not start with the assumption that you migrate straight from one to 
the other, particularly if your existing mechanisms involve the 
dangerous and rickety things (e.g. PID files) that proper service 
management is designed to avoid in the first place, or things such as 
"subsystem" lock files which proper service management has no need of by 
its very nature.  "Type=forking" specifies a quite specific readiness 
protocol that your daemon has to enact, lest it be regarded as failed.  
It's isn't a catch-all for anything that might fork in any possible 
way.  And service managers know, by dint of simply remembering, what 
processes they started and whether they've already started them.

I've been collecting case studies of people who have migrated to systemd 
exceedingly badly, and constructed some quite horrendous systems, 
because they've done so without either consideration of, or 
understanding of, how their sytems actually work.  Here's one candidate 
that I have yet to add, because I'm hoping that now they've been told 
that they are going wrong they will correct themselves, whose errors are 
good to learn from.

There's a computer game called "ARK: Survival Evolved".  It's daemon is 
a program named ShooterGameServer.  To run this program continually as a 
daemon, someone named Federico Zivolo and a couple of other unidentified 
people came up with the somewhat bizarre idea of running it under 
screen, and using screen's commands to send its pseudo-terminal an 
interrupt character, in order to send a SIGINT to the daemon when it 
came time to shut it down.  They wrapped this up in a System 5 rc 
script, taking the conventional "start" and "stop" verbs, named 
"arkmanager".  Its prevent-multiple-instances system was not lock files, 
but grepping the process table.

Wrapped around this they put another System 5 rc script, named 
"arkdaemon", which also took the conventional "start" and "stop" verbs, 
and which treated the wrapper "arkmanager" script as the daemon, 
recording the process ID of the shell interpreter for the "arkmanager" 
script in a PID file, as if it were the actual daemon's process ID.  It 
also did various other bad things that proper service managers 
eliminate, including grepping the process table (again), abusing su to 
drop privileges, using arbitrary 5 second sleeps to make the timing 
almost work, and (sic) hardwired ECMA-48 SGR sequences to change the 
colour of output that isn't going to a terminal in the first place.

Then they wrote a systemd service unit file, "arkdeamon.service" (sic), 
that did this:

 > ExecStart=/etc/init.d/arkdaemon start
 > ExecStop=/etc/init.d/arkdaemon stop
 > Type=forking

A couple of days ago, I pointed out the errors of even starting down 
this route to them, and wrote a systemd unit file for them that actually 
starts the daemon directly from systemd; no PID files, abuses of su, 
racy grepping of the process table, abritrary sleeps, or incorrect 
"forking" readiness protocol necessary.  Set the account with User= ; 
set the environment with Environment= ; and run the program with 
ExecStart=/home/steam/ARK/ShooterGame/Binaries/Linux/ShooterGameServer 
plus some options.  Other stuff, like software upgrades, one then builds 
on top of the service management layer, not beneath it.  I also pointed 
out to them that I had been beaten in this regard by some 4 days by the 
(again unfortunately unidentified) people who wrote 
http://ark.gamepedia.com/Dedicated_Server_Setup#Automatic_Startup , 
whose service unit was pretty much the same as the one that I had 
independently written (as one would expect, indeed).

If you understand how your daemon is run in the first place, then you 
end up with what I and the gamepedia people did.  If you just think that 
you wrap what you already have, using "forking" to imperfectly paper 
over the cracks, you oftentimes end up with an utterly horrendous mess.