[systemd-devel] SysVInit service migration to systemd

[Lesley Kimmel]

Jonathan;

Thanks for the background and information. Since you clearly seem to have a grasp of systemd please humour me with a few more questions (some of them slightly ignorant):

a) Why are PID bad?
b) Why are lock files bad?
c) If a/b are so bad why did they persist for so many years in SysVInit?
d) Generically, how would you prescribe to use systemd to start Java processes (for Java application servers) that are typically started from a set of relatively complex scripts that are used to set up the environment before launching the Java process? It seems that you are advocating to call, as directly as possible, the target service/daemon. However, some things don't seem so straight-forward.

Thanks again!
Lesley Kimmel, RHCE
Unix/Linux Systems Engineer

> Date: Sun, 28 Jun 2015 14:29:40 +0100
> From: J.deBoynePollard-newsgroups at NTLWorld.com
> To: systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] SysVInit service migration to systemd
> 
> 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.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150629/06493882/attachment-0001.html>