[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay
#24158: I get this error "Looks like our kernel doesn't have the support for KIST
anymore." on my relay
---------------------------+------------------------------------
Reporter: Dbryrtfbcbhgf | Owner: (none)
Type: defect | Status: needs_revision
Priority: Medium | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-sched | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------+------------------------------------
Changes (by dgoulet):
* status: new => needs_revision
Comment:
@Dbryrtfbcbhgf: The notice shouldn't be logged more than once after KIST
has been disabled. So if this log is being seen over and over (probably at
each consensus), we have a bug. Are you seeing it constantly? If yes, what
time rate?
{{{
[notice] Looks like our kernel doesn't have the support for KIST anymore.
We will fallback to the naive approach. Remove KIST from the Schedulers
list to disable.
}}}
`kist_no_kernel_support` is set to 1 in the case of no support for KIST so
the fallback is KISTLite. That notice can't be logged after that unless
that value changes back to 0 which it doesn't unless tor restarts.
I think that notice will be logged each time the conf changed or new
consensus while having KIST disabled by no kernel support. We should
probably log it once and only once.
{{{
log_notice(LD_SCHED, "Scheduler type KIST has been disabled by "
"the consensus or no kernel support.");
}}}
With regards of logging the change even though the user never specified
anything in `Schedulers`, I do think we should keep it because KIST is a
default and if there was a fallback, user should get informed. This is
especially important on non-Linux system where KIST is not supported which
informs of the choice of Tor at startup. But it shouldn't be that loud
especially after bootstrap.
@pastly: The man page change lgtm *except* that I wouldn't put `and
doesn't prioritize very well`. It is good to be honest but then also it is
kind of weird to document how shitty it is in the manual page but still
offer the option :P.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24158#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs