Opened 9 years ago

Closed 2 years ago

#2191 closed defect (wontfix)

Send all error-level log messages to controllers

Reported by: rransom Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Right now, if:

  • an assertion fails inside Tor,
  • Tor has disabled sending log messages to its controllers, and
  • Tor is not logging directly to syslog or any file descriptors,

Tor will crash silently, with no record anywhere of why it crashed. This is especially bad for users of the Tor Browser Bundles and Vidalia Bundles, which are preconfigured to not log to disk.

Tor should:

  • only log error-level messages when a crash is imminent (e.g. in tor_assert),
  • send log messages to all non-callback log sinks before sending them to callbacks, and
  • send error-level log messages to controllers regardless of whether logging to controllers is otherwise disabled (with the disable_control_logging function or a wrapper around it).

Child Tickets

Change History (14)

comment:1 Changed 9 years ago by nickm

only log error-level messages when a crash is imminent (e.g. in tor_assert)

ERR is not just for crashes; it's for any nonrecoverable error that means Tor needs to stop right now. Probably that's close enough though.

send error-level log messages

We should consider some kind of fast-path for sending error logs to controllers: we could bypass the whole buffered network IO layer and just call send() on the log message.

comment:2 in reply to:  1 Changed 9 years ago by rransom

Replying to nickm:

We should consider some kind of fast-path for sending error logs to controllers: we could bypass the whole buffered network IO layer and just call send() on the log message.

Sending the pattern CRLF "." CRLF "421 " Message CRLF on the control connection, then closing the connection, would unambiguously deliver a message to the controller, but is likely to confuse and/or crash existing controllers before they even read the message. I think that's the least bad option for reporting a fatal error at the moment, but it'll need to be explicitly requested with USEFEATURE.

comment:3 Changed 9 years ago by nickm

Hmm. The CRLF "." CRLF would tend to make our existing controller grammar pretty much bunk, and would also make it hard to tell a truncated data chunk from a completed one.

How about if we used a character otherwise forbidden in the controller grammar, like ESC? That way we can change the grammar from :

  Reply = SyncReply / AsyncReply

to

  Reply = SyncReply / AsyncReply / ( TruncatedReply Error )

  TruncatedReply = TruncatedReplyLine / TruncatedData

  TruncatedReplyLine = ReplyText ESC ESC CRLF
  TruncatedData = (define this)

  Error = STATUSCODE SP "ERROR" [SP "ReplyText"] CRLF [Data]

Of course, we'd still need to use the USEFEATURE trick. And I note that ReplyText isn't defined right now, so we'll need to think about that too.

comment:4 Changed 9 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

I am not currently seeing any way to do this correctly without a fair bit of design and discussion, so that would argue against doing it in 0.2.2.x-final. :(

Bumping to 0.2.3.x unless somebody thinks of a clever hack that doesn't need so much protocol revision and whose implementation is dead simple.

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Bumping to 0.2.4.x for the same reason as above :/

comment:6 Changed 7 years ago by nickm

Keywords: tor-client added

comment:7 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:8 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:9 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:10 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:11 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:12 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:13 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:14 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: newclosed

Wontfix: if controllers do not have ERR events turned on, they won't get any. If they can actually handle receiving ERR events, then they can SETEVENTS to get them

Note: See TracTickets for help on using tickets.