From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1627 Path: news.gmane.org!not-for-mail From: "rehan khan" Newsgroups: gmane.comp.sysutils.supervision.general Subject: RE: using runit as init Date: Sun, 13 Jan 2008 21:06:21 -0000 Message-ID: References: <200801032151.21524.list-supervision@augensalat.de> <200801131128.53994.mike@geekgene.com> <6A64B0D384404190ACB76E0A376CD148@home.internal> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85628.25F5DB2D" X-Trace: ger.gmane.org 1200258398 6376 80.91.229.12 (13 Jan 2008 21:06:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2008 21:06:38 +0000 (UTC) To: "Mike Buland" , Original-X-From: supervision-return-1862-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Jan 13 22:06:58 2008 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1JEA2h-0000If-Bz for gcsg-supervision@gmane.org; Sun, 13 Jan 2008 22:06:55 +0100 Original-Received: (qmail 2887 invoked by uid 76); 13 Jan 2008 21:06:37 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 2881 invoked from network); 13 Jan 2008 21:06:37 -0000 Original-X-Trace: 18120364/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.32 X-SBRS: None X-RemoteIP: 62.241.162.32 X-IP-MAIL-FROM: rehan.khan@dsl.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH8Mikc+8aIg/2dsb2JhbACCbqN4 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <6A64B0D384404190ACB76E0A376CD148@home.internal> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: using runit as init thread-index: AchWFqH/pZobTsMaTne4xDv4A5M6FQABjUrw Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1627 Archived-At: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85628.25F5DB2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AFAICS the redhat scripts send a term, wait 10 secs then send a kill to = the mysql processes ending with the parent process. >From what you guys are saying this is not the right way to stop mysql? = If it isn't then someone should probably mention it to Redhat :) Rehan -----Original Message----- From: Mike Buland [mailto:mike@geekgene.com] Sent: 13 January 2008 19:01 To: supervision@list.skarnet.org Subject: Re: using runit as init Hey, a complicated program they made is better than one I have to = manage. If you do read the docs, they don't handle signals in mysqld, like I = say,=20 mysqlmanager does. They don't defend it, but they do explain that the = only=20 way to safely shutdown mysql is to send it a command via the named = socket. =20 Since this can't be done easily from the commandline without a password, = unless you configrue mysql to accept the command from root without a=20 password, then this seems like a pretty decent solution, since this = program=20 basically supervises it's child mysql processes and sends them a safe=20 shutdown signal when the mysqlmanager program receives a term signal. All the scripts I've read from debian and redhat just send a = kill...although=20 this seems alright most of the time (and they are official scripts), = that=20 doesn't gurantee that data is flushed to disk, if mysql is in the middle = of a=20 large operation, that data is gone. This solution does solve that = problem,=20 and keep runit from waiting for mysql to TERM. --Mike On Sunday 13 January 2008 11:39:56 am Charlie Brady wrote: > On Sun, 13 Jan 2008, Mike Buland wrote: > > On Sunday 13 January 2008 08:36:31 am Charlie Brady wrote: > >> On Sat, 12 Jan 2008, Vincent Danen wrote: > >>> mysqld is no more complex than anything else. > >> > >> Have they fixed it then, so that the master process kills children > >> before dying? > > > > Yes, read the (very lame) docs on mysqlmanager. It also now = responds to > > other signals (such as term) so it plays nicely with runit :) > > This might actually mean "no". They haven't fixed the signal > handling in mysqld, but have instead introduced a new complicated = program > to try to work around the issues. > > > mysqlmanager was introduced sometime in mysql 5, not sure when. > > Introduced in 5.0.3. Not used by default since 5.0.4. ------_=_NextPart_001_01C85628.25F5DB2D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: using runit as init

AFAICS the redhat scripts send a term, wait 10 secs = then send a kill to the mysql processes ending with the parent = process.

>From what you guys are saying this is not the right way to stop mysql? = If it isn't then someone should probably mention it to Redhat :)


Rehan


-----Original Message-----
From: Mike Buland [mailto:mike@geekgene.com]
Sent: 13 January 2008 19:01
To: supervision@list.skarnet.org
Subject: Re: using runit as init


Hey, a complicated program they made is better than one I have to = manage.

If you do read the docs, they don't handle signals in mysqld, like I = say,
mysqlmanager does.  They don't defend it, but they do explain that = the only
way to safely shutdown mysql is to send it a command via the named = socket. 
Since this can't be done easily from the commandline without a = password,
unless you configrue mysql to accept the command from root without a
password, then this seems like a pretty decent solution, since this = program
basically supervises it's child mysql processes and sends them a = safe
shutdown signal when the mysqlmanager program receives a term = signal.

All the scripts I've read from debian and redhat just send a = kill...although
this seems alright most of the time (and they are official scripts), = that
doesn't gurantee that data is flushed to disk, if mysql is in the middle = of a
large operation, that data is gone.  This solution does solve that = problem,
and keep runit from waiting for mysql to TERM.

--Mike

On Sunday 13 January 2008 11:39:56 am Charlie Brady wrote:
> On Sun, 13 Jan 2008, Mike Buland wrote:
> > On Sunday 13 January 2008 08:36:31 am Charlie Brady wrote:
> >> On Sat, 12 Jan 2008, Vincent Danen wrote:
> >>> mysqld is no more complex than anything else.
> >>
> >> Have they fixed it then, so that the master process kills = children
> >> before dying?
> >
> > Yes, read the (very lame) docs on mysqlmanager.  It also = now responds to
> > other signals (such as term) so it plays nicely with runit = :)
>
> This might actually mean "no". They haven't fixed the = signal
> handling in mysqld, but have instead introduced a new complicated = program
> to try to work around the issues.
>
> > mysqlmanager was introduced sometime in mysql 5, not sure = when.
>
> Introduced in 5.0.3. Not used by default since 5.0.4.

------_=_NextPart_001_01C85628.25F5DB2D--