public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Martin Schlemmer <azarah@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: RE: [gentoo-dev] init script guidelines
Date: Tue, 19 Jul 2005 23:53:57 +0200	[thread overview]
Message-ID: <1121810037.4621.16.camel@lycan.lan> (raw)
In-Reply-To: <1121798402.26224.14.camel@cgianelloni.nuvox.net>

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Tue, 2005-07-19 at 14:40 -0400, Chris Gianelloni wrote:
> On Tue, 2005-07-19 at 14:08 -0400, Eric Brown wrote:
> > My point is that Snort and Apache are not alone in this, so I suppose
> > quite a few upstream developers just disagree with us on what proper
> > initialization means.  Why should our users suffer?
> 
> They shouldn't, but that doesn't mean implementing some half-baked hack
> to resolve the situation.  It might be better to instead patch the
> daemon in question and send the patches upstream.  Upstream developers
> (usually) are much more willing to make changes when you've done the
> work for them... ;]
> 

I know Roy already did the sleep check in rc-services.sh which is small,
and I think fairly acceptable, but like Mike said, you cannot make it
longer and then do it for all, as some arches is just too slow, and I'm
going to guess we have a less than 10% of services with this issue?

Personally I think the issue should be taken on a per-package basis, and
if somebody sees an issue, open a bug against snort/apache/whatever to
do a timeout, and then check some or other way if its actually started.

For the developer awareness issue ... its not always such an open/shut
case.  I can't remember what had this issue, but some daemon only
displayed this issues with slower boxes, and not the faster ones, so it
really will totally depend on what type of hardware the developer have
or not.  So yeah, better awareness by adding a section to the developer
manual or something to the test for new developers might help, but not
fool proof.


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2005-07-19 21:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-19 18:08 [gentoo-dev] init script guidelines Eric Brown
2005-07-19 18:40 ` Chris Gianelloni
2005-07-19 20:43   ` Michael Cummings
2005-07-19 21:07     ` Chris Gianelloni
2005-07-19 21:53   ` Martin Schlemmer [this message]
2005-07-20  6:30     ` Roy Marples
2005-07-19 20:03 ` Mike Frysinger
  -- strict thread matches above, loose matches on Subject: below --
2005-07-19 19:39 Eric Brown
2005-07-19 16:42 Eric Brown
2005-07-19 17:22 ` Chris Gianelloni
2005-07-19 17:45 ` Mike Frysinger
2005-07-19 18:00 ` Roy Marples
2005-07-19 22:16   ` Francesco R
2005-08-23 14:09   ` Paul de Vrieze
2005-08-31  7:13     ` Roy Marples
2005-08-31  8:05       ` Roy Marples
2005-08-31  8:24         ` Georgi Georgiev
2005-08-31 17:38       ` Roy Marples
2005-07-19 18:14 ` Francesco R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1121810037.4621.16.camel@lycan.lan \
    --to=azarah@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox