Re: Debian boot system
On Sat, Oct 07, 2000 at 04:22:10PM +0200, Eyal Lotem wrote:
> On Sat, 07 Oct 2000, Michael Moerz wrote:
>
> > Oh, yeah, why not patch every daemon in this and that direction adding
> > this feature and an other, so making it impossible to run unpatched
> > daemons.
> Patch every daemon? You misunderstood me, just redirect the output of the
> script from the Makefile itself.
> Any extra fucntionality such as maintainance of the Makefiles is possible to
> add to packages.
>
Indeed I misunderstood you.
> > > Yes, I have mixed output, the dots are everywhere :) All fixable.
> >
> > All fixable? did you ever think of missing output? Did you ever really
> > read the make - infopage ? I did, I know make, and I have used it to it's
> > best. OUTPUT might get lost, mixed and whatever. That is not desireable.
> > And opposing someone to boot non parallelised when having problems won't
> > solve them. As I stated before a way to determine when and what was
> > running is the only way to disolve this issue. There are no other nifty
> > tricks that can be played around this.
> Output can get lost? I went through the INFO page briefly, and read about
> the mixed output concerns further, but there's no mention of losing output.
> Can you direct me to the exact place where that is written? The simple
> collection of individual output logs of the init scripts, with timestamps on
> everything, should be quite enough info. to know what happened when, very
> specifically.
>
Now you misunderstood me. I did not really mean output to get lost, I simply meant mixed output and therefore you get lost about where what output did come from.
That would indeed be eliminated by redirecting output.
But an other issue would be to deal is when services fail to start. Normally make stops when the exitcode of a command != 0. You could use the option -k, but that would keep it going even when we have a service depending on the failed service. But it is also highly undesireable to not start other services that do not depend on the failed service. I am not really sure if this issue is going to be solved so gracefully.
> If the computer hanging makes the daemon lose its last messages, when
> parallilsm is turned off, how is it ANY different from the traditional SysV
> last lines of the logs getting lost?
> When having problems, I think its safe to say you want and will disable
> parallilsm. Without parallilsm, there is not much of a difference between
> SystemV and the Makefile, from the aspect of logs, the way the order of the
> commands is deduced is the only difference in that case.
>
Ok. What you will have after a broken parallelised boot is a handfull (or more)
daemon output files that state what was done when. It would be some work to read all finding the line where everything broke. Perhaps a tool that puts all together correctly would be handy then, wouldn't it?
Anyway, what I tried to point out is that situations might occur where the package maintainers didn't know that their packages have a parallelisation problem. I don't have a concrete example, but this might happen. Then of course switching back to non parallelised operation would solve it. When the problem isn't solveable you will stay at non parallelised boot, otherwise you would make it back.
> > I really do not wanna turn you down nor I intend to offend your idea. I
> > think it's really nice having such a parallelised boot, but not when I
> > will loose determinisation what caused my computer to stop at boot.
> Cancelling out parallilsm temporarily should be a resolution of most of these
> problems.
> Other problems in parllilsm itself are resolvable by checking which daemons
> were still unloaded (those loaded _DO_ appear in the logs), and checking
> their dependencies.
>
yeah, a tool for this might be handy :), I know now I am repeating.
If the error/continue - dependency problem is solved, then I think nothing stands against using your new Makefile thing for booting. Actually I would appretiate it since I have 2 processor and one is always idle when booting, except the service is threaded and doesn't wait for the disk so long.
I support you in your ongoing design phase, asking for any problem that may arrise.
--
kind regards,
Michael Moerz
Reply to: