В Mon, 29 Jun 2015 08:58:11 -0500 Lesley Kimmel <ljkimme...@hotmail.com> пишет:
> 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? PID files as the primary way to track running service are too unreliable - it is easy for a service to die without removing PID file. PID file as a mean to track service startup the way systemd does it is IMHO just fine. Actually it is the only way for a service to announce its readiness without adding explicit systemd support (Type=notify). > 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-newsgro...@ntlworld.com > > To: systemd-devel@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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
