> > severity 309014 important > > thanks > >
Uh, oh yes, and sorry for the error. Yes, indeed, it doesn't renders the package unusable for everybody. > > On Sun, May 15, 2005 at 03:50:27PM +0200, Matthijs Mohlmann wrote: > > > I have a Dual AMD Athlon 1800+ (MP) and running the commands above > > > wouldn't crash atd. > > > > > I also vote to downgrade the severity to important, the bug causes not a > > > unusable package. > > > > Running this on my HT P4 makes my laptop's fan unhappy, but it does not seem > > to trigger a crash. Curious... Already reproduced, on the same computer. > > > > IIRC DoS bugs are normally important anyway (not grave), and this one > > seems particularly difficult to exploit, so I'm going to go ahead and > > downgrade it. Yes, you're right. > FWIW, I can't reproduce on either an amd64 single CPU or a p4 dual ht > cpu system. It does drive the load up interestingly, and could for the > OP have caused the oom killer to kck in and kill atd, but that wouldn't > be a bug in atd. Doesn't seem me like this... 1) On this computer, the strace caused the daemon to run slower, but didn't triggered the bug (I tried with trace not redirected, or redirected on an nfs-exported file). 2) On the contrary, quickly (well, some minutes) after having stopped the stracing, atd crashed already. Trace not available, of course, but if it were an oom-killer question, strace shouldn't have any impact on it, shouldn't it? 3) On the Mandrake, curiously enough, the strace I once saw was showing that atd received many signals, and very quickly, but no SIGKILL (the oom-killer kills with SIGKILL, IIRC), and showed that the last syscall of atd was exit_group(). A killed process shows +++ killed by SIGKILL +++, it has no time calling exit_group(). On the other hand, I can't figure myself the reason for which a daemon would terminate himself this way, except if explicitely asked to stop. Emmanuel ------------------------------------------------- envoy� via Webmail/IMAG !
