From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 987CA138BF3 for ; Tue, 18 Feb 2014 12:07:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E281E0C64; Tue, 18 Feb 2014 12:07:36 +0000 (UTC) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 49939E0C41 for ; Tue, 18 Feb 2014 12:07:35 +0000 (UTC) Received: from [212.54.42.137] (helo=smtp6.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WFjSY-0001FR-N7 for gentoo-user@lists.gentoo.org; Tue, 18 Feb 2014 13:07:34 +0100 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp6.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WFjSY-0000w7-64 for gentoo-user@lists.gentoo.org; Tue, 18 Feb 2014 13:07:34 +0100 Received: from www.antarean.org (net.lan.antarean.org [10.20.13.13]) by data.antarean.org (Postfix) with ESMTP id 7A9204B for ; Tue, 18 Feb 2014 13:07:10 +0100 (CET) Received: from 145.72.98.1 (SquirrelMail authenticated user joost) by www.antarean.org with HTTP; Tue, 18 Feb 2014 13:07:10 +0100 Message-ID: In-Reply-To: References: <52FF84CE.2050301@libertytrek.org> <52FF9D58.3000608@libertytrek.org> <201402152023.10543.michaelkintzios@gmail.com> <5300DD51.5060207@libertytrek.org> <5300EA3A.5020801@gmail.com> <24165346-F62B-4CD4-BB43-0D5A68BE0004@stellar.eclipse.co.uk> <530268AE.3050603@gmail.com> <53032C35.3060307@gmail.com> Date: Tue, 18 Feb 2014 13:07:10 +0100 Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org User-Agent: SquirrelMail/1.4.22 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Ziggo-spambar: - X-Ziggo-spamscore: -1.5 X-Ziggo-spamreport: BAYES_00=-1.9,RDNS_DYNAMIC=0.982,RP_MATCHES_RCVD=-0.552 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 3dc47063-4fa7-4c32-aff3-f507f936dc9d X-Archives-Hash: 50eeadcb472bdb38dec68df758f7a776 On Tue, February 18, 2014 12:54, Mark David Dumlao wrote: > On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld wrot= e: >> On Tue, February 18, 2014 10:47, Alan McKinnon wrote: >>> On 18/02/2014 05:46, Mark David Dumlao wrote: >>>> I used to use cherokee. Fast, light, awesome, and with a web admin. >>>> The init script always failed me. /etc/init.d/cherokee stop was not = a >>>> guaranteed stop to all forked cherokee processes - the parent pid >>>> dies, but some forked process or something, usually related to >>>> rrdtool, doesn't. Or the parent does exit and erases the pid file bu= t >>>> it returns control immediately and its not yet done exiting. Somethi= ng >>>> like that or other. Point is, I've several times had to ps aux|grep >>>> ... kill; zap; start - on production servers. >>> >>> >>> Valid point. Other than vixie-cron (damn thing just never seems to di= e >>> properly on any platform so restarts always fail) I don't really run >>> into these issues >> >> Interesting, I have never had issues with restarting vixie-cron using >> the >> supplied init-scripts. >> >>> What I do run into is daemons that drop privs on start up, like >>> tac_plus. Unwary new sysadmins always try start/stop it as root, >>> causing >>> an unholy mess. Root the owns the log and pid files, when tac_plus >>> drops >>> privs it can't record it's state so continues to service requests but >>> fails to log any of them. For an auth daemon, that's a serious issue. >> >> Shouldn't sysadmins use the init-scripts for that? >> If done correctly, permissions should not be an issue. >> >> Restarting services without keeping file ownership into account will >> always cause issues. Regardless of the init-system used. >> > > That's just the thing though. As a sysadmin, how do you debug a service > that isn't starting to begin with? This isn't what Alan was talking about. He was talking about restarting an existing, working service. > Let's say your new to the service. > You're > not even sure if you got the config right the first time around. Or may= be > you're adjusting a setting somewhere, and you're confused why it > isn't taking effect. In an environment where Alan works, I wouldn't be the only person around. There should be someone on call who knows. > All the /upstream documentation/, all the /man pages/, all the > /usr/share/doc > stuff will tell you to start it _raw_. The init script obscures the > starting options, > environment variables, and sometimes even the running user from you. Wh= at > are > you gonna do, play a human shell script parser? Nobody's perfect, do it > enough times and you're going to casually gloss over the line where > --safe-mode is appended to the string depending on the phase of > the moon... > > If you're lucky, you've never had to start an unfamiliar service, or de= bug > someone else's unfamiliar config under time pressure... I have been on both ends of this. I have multiple times been in a situation where I was under time-pressure to get services running again on unfamiliar systems. Talking untrained admins through the process by phone-communication only. It is not easy, but by staying calm and focused, mistakes are avoided. Also, in my experience, a calm systematic approach is usually faster then the cowboy-method of trying everything I can find on Google. I have also, too often, had to clean up the mess caused by these cowboy tactics. -- Joost