Opened 4 years ago

Closed 4 years ago

#18248 closed defect (not a bug)

tor logging twice when --+Log argument and config are used

Reported by: reezer Owned by:
Priority: Low Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version: Tor: 0.2.8.1-alpha
Severity: Minor Keywords: easy
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When specifying the Log option to the same place twice various messages will be logged twice.

Specifying

# On the command line:
--+Log notice file /var/log/tor

# In torrc:
Log notice file /var/log/tor

will result in messages like those:

Feb 05 11:05:41.000 [notice] Bootstrapped 0%: Starting
Feb 05 11:05:41.000 [notice] Bootstrapped 0%: Starting
Feb 05 11:05:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 05 11:05:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 05 11:05:54.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Feb 05 11:05:54.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Feb 05 11:05:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
Feb 05 11:05:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.

In a way one could say that's expected, but I think equivalent options should maybe be deduplicated.

This occurs on: Tor v0.2.8.1-alpha (git-9093e3769746742f) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2f and Zlib 1.2.8.

Child Tickets

Change History (8)

comment:1 Changed 4 years ago by teor

Keywords: easy added
Milestone: Tor: 0.2.9.x-final
Priority: MediumLow
Severity: NormalMinor

I can't think if any use cases where duplicating log messages would be a desirable behaviour. But it is the behaviour documented in the tor man page.

Rather than de-duplicating, we could at least warn if tor detects the same log option listed twice.

(It's not always possible to tell, what if /var/log/tor and /private/var/log/tor are the same file?)

comment:2 Changed 4 years ago by reezer

Do you mean symlinks in your last statement? Or something else? I think it might make sense to just look for identical paths as a solution that would work for most cases.

Another thing that might be a bit harder is preference (how is this handled for other options? I assume the command line overwrites things). If one does specifies different log levels for a file that could maybe become something to think off? Either having one take precedence and overwrite the other or take the higher log level to not miss important messages.

comment:3 Changed 4 years ago by cypherpunks

I fail to see how this is a 'defect'.

You are explicitly telling tor to add the same value to the same option (the '+' prefix).

Even if you change this into an 'enhancement', I see little appeal in this de-duplication mechanic: it would have to be special-cased for different options. It's easy to imagine options where several identical values make perfect sense.

Do you mean symlinks in your last statement? Or something else?

Unix has any number of ways in which 2 names can actually refer to the same object.

This is 'notabug' for me.

comment:4 in reply to:  3 Changed 4 years ago by reezer

Replying to cypherpunks:

I fail to see how this is a 'defect'.

Just maybe strange/unexpected behavior?

Do you mean symlinks in your last statement? Or something else?

Unix has any number of ways in which 2 names can actually refer to the same object.

That's exactly why I asked. I was wondering whether it is something that could be detected.

Not saying it's a big bug or anything, just something that I ran into when setting up a new Tor relay when copying over some parts of the config, noticing that the package for the OS starts Tor with this flag per default.

Like I wrote when creating this ticket "In a way one could say that's expected". It's still weird and without any actual use to do that. It *could* cause confusion, when enabling different logs and forgetting about the parameters that might be passed by the init system or in general outside of the configuration.

I'm fine with this not being changed. Fixed the config on my system. Just wanted to report it in case it was unintentional.

comment:5 Changed 4 years ago by nickm

I'm inclined to close this as not-a-bug. If the user asks us to log all notice messages to stdout twice, we log all notice messages to stdout twice. The output is a little confusing, but the input is a little confused. :)

comment:6 in reply to:  5 Changed 4 years ago by reezer

Thinking about it, I think you are right. I instantly knew/had a guess about what's going on, so I think it's also not really confusing.

comment:7 Changed 4 years ago by bugzilla

There are so many severe bugs in TBB still unfixed, and no dev online. But here users and devs are talking about multi-logging: is this a bug or feature? Great...

comment:8 Changed 4 years ago by nickm

Resolution: not a bug
Status: newclosed
Note: See TracTickets for help on using tickets.