Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] [bugzilla-daemon@bugs.sourcemage.org: [Bug 13114] simpleinit doesn't show output of stopping services on recent kernels]

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] [bugzilla-daemon AT bugs.sourcemage.org: [Bug 13114] simpleinit doesn't show output of stopping services on recent kernels]
  • Date: Wed, 28 Feb 2007 20:34:27 -0800

On Wed, Feb 28, 2007 at 10:13:16PM -0600, Jeremy Blosser wrote:
> On Feb 28, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> > On Wed, Feb 28, 2007 at 04:27:36PM -0600, Jeremy Blosser wrote:
> > > On Feb 28, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> > > > I thought I might forward this onto the discussion. The major issue
> > > > with simpleinit-msb on newer kernels has now been isolated (not that
> > > > there aren't still minor issues). :)
> > > >
> > > > A lot of people helped contribute to fixing this bug. I'd like to
> > > > thank
> > > > them all, including David Kowis, Jeremy Blosser, Andrew Stitt, Juuso
> > > > Alasuutari, David Brown, George Sherwood, and Arwed v. Merkatz.
> > > >
> > > > Excellent example of teamwork.
> > >
> > > That's one spin. ;-P While I definitely appreciate everyone helping on
> > > this, this is to me an excellent example of why we need other options,
> > > even
> > > just one other option for the short term. That's too many people and
> > > too
> > > many hours spent on finding something that ended up being this trivial,
> > > isn't it?
> > >
> > > "How many SMGL devs does it take to screw in a lightbulb?"
> >
> > This bug was extra hard for a few reasons that aren't necessarily
> > expected in the future:
>
> No. The bug was hard because we had no idea how the internals worked to
> know where we might start looking for the problem in the code, so we had to
> start with stracing the symptoms and work backward from there. If someone
> who actually supported it and knew what it was doing heard the symptoms
> they probably could have solved it nearly immediately because they'd know
> where the messages originated and could start there. And that's assuming
> it wouldn't have been fixed during the course of normal development as they
> tracked relevant kernel and libraries changes. You know, the kinds of
> maintenance people do with maintained software.

What messages? It was a lack of messages.

If you find an announcement for that interface change beyond a patch to
lkml, then perhaps, however that change was more fundamental than for an
init system.

>
> > * There was an unrelated kernel change in signaling that distracted the
> > system call traces.
> >
> > * There was a kernel change that changed file semantics significantly.
> >
> > * The code problem was in a small block of code not allowing userspace
> > init to find the problem, since it only acts directly on the console in
> > non-userspace mode.
>
> All of these were only issues because we don't know or regularly support
> this code. They distracted us until we could rule them out because we
> didn't know what was expected behavior and had to disprove everything else
> that looked anamolous wasn't a problem. I'm frankly embarassed it took us
> that long to find a bug so simple, whether I think it was really our
> problem to solve or not.

The distraction I vocally said was probably a meaningless distraction
on first read? They didn't distract me.

>
> > Other than that, I doubt most init systems even have a userspace init
> > mode and have zero bugs and never had issues with portability due to
> > kernel changes.
>
> Of course nothing else is perfect. That is not the point. The point is
> having a path to a resolution that makes sense. There are bugs, and then
> there is bit rot.

We're all happy to maintain bash code against bash-interface-changing
bit-rot, but a small set of C files is too hard?

>
> > That we handled it is reason enough to believe that we're capable of
> > maintaining deep code like this on our own. Yes, we might not want to,
> > and that's reason enough to make alternatives available, but we mustn't
> > overreact and remove simpleinit-msb as a result of this bug.
>
> It is not a question of *capability* it is a question of *purpose*. We no
> doubt had capability during the scm discussions to reverse engineer
> perforce and make a GPL clone of that and maintain that ourselves for our
> own use. But it would have been a poor use of our resources and it would
> have had nothing to do with our purpose as a distribution. Yes, I know the
> scale of those two things is very different, but the principle is the same.
>
> And if you think this talk of replacing simpleinit is somehow new or
> specific to this particular bug you haven't been paying attention. That's
> like the arguments each time p4 was down that "we shouldn't talk about
> replacing it just because it's down this one time", no matter how many
> times it had been down before, or how many other issues we had with it.
> (Insert standard disclaimer that it wasn't p4's or Tony's fault when it was
> down, and reminder that it didn't matter.)

You've fallen into the replacement versus complement hole with this
paragraph. I thought the consensus was on complementing the init system
with choices, not replacing it. That's all I'm vocal for.

>
> > There are a few other improvements that nobody is mentioning in these
> > discussions that I'd like to make to it that could be considered
> > detriments, but I don't think the level of argument against
> > simpleinit-msb has reached that level of sophistication (yet).
> >
> > Maybe the initng maintainer will bring the sophistication up and give
> > reason enough to say that simpleinit-msb is fundamentally flawed.
>
> People make comments and requests around the other shortcomings of
> simpleinit all the time. There are plenty of bugs filed on things our init
> system doesn't support. Yes, the bugs are filed more against init.d than
> simpleinit, but the bottom line is the same: we are piling up issues in
> this area quicker than we are resolving them, and while that's hardly
> unique in the project overall, it's an area where we arguably shouldn't
> even be operating.

You filed one bug requesting proper respawn support and gave a
workaround.

That's all that shows up filed against simpleinit.

I think a good audit of just where you think simpleinit is deficient is
necessary for this discussion so we can ensure the new setups will also
support them.

>
> > I, for one, don't think it is fundamentally flawed.
>
> If you want to pick up simpleinit and make maintaining it your pet project
> and see it included as an option here and elsewhere, you're certainly free
> to do so, but don't expect the project to agree it's something "we" are
> doing. simpleinit-msb is not a Source Mage component. The fact is we only
> have this discussion and apparent willingness to work on init bugs when
> people complain loudly enough that it's flawed, and then they still never
> get resolved. The project needs to move past this so it stops giving us
> black eyes.

I'd rather rewrite it more cleanly, which I may do. I'll go far as to
say that if a bug shows up in simpleinit-msb again, I'll put my best
effort in to fix it with what time I have available. I'm going to setup
a Xen testbed at home just for situations like this that involve init.

It's not designed the way I would like. The problem is that the
replacements that exist now and that are developing are adding
complexity. I want to reduce it even further and move non-essential
items out of it.

If somebody has a potential init system that looks like that, let me
know and I'll probably try it out and abandon simpleinit-msb (then do
what you want with it).

I'm more a fan of blackbox-style minimalism.

Seth




Archive powered by MHonArc 2.6.24.

Top of Page