Passes the test suite entirely, except whatever we do when bridges
configuration is chosen makes the tor process crash. Tor Launcher says
“Could not connect to Tor control port.”, and indeed Tor has
segfaulted. /var/log/tor/log reads:
<Mar 02 15:00:46.000 [notice] Tor 0.2.6.3-alpha (git-a8fbe3b035e0cb1f) opening new log file.Mar 02 15:00:46.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.Mar 02 15:00:47.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.Mar 02 15:00:47.000 [notice] Bootstrapped 0%: StartingMar 02 15:00:47.000 [notice] Delaying directory fetches: DisableNetwork is set.Mar 02 15:00:47.000 [notice] New control connection opened from 127.0.0.1.Mar 02 15:00:47.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.Mar 02 15:00:47.000 [notice] Caching new entry debian-tor for debian-torMar 02 15:00:47.000 [notice] Tor 0.2.6.3-alpha (git-a8fbe3b035e0cb1f) opening log file.Mar 02 15:00:47.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.Mar 02 15:00:47.000 [info] cell_ewma_set_scale_factor(): Disabled cell_ewma algorithm because of value in Default valueMar 02 15:00:47.000 [info] options_act(): Worker-related options changed. Rotating workers.============================================================ T= 1425308447Tor 0.2.6.3-alpha (git-a8fbe3b035e0cb1f) died: Caught signal 11/usr/bin/tor(+0x128f2e)[0xf7707f2e]/lib/i386-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x1d)[0xf7198e8d]/lib/i386-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x1d)[0xf7198e8d]/lib/i386-linux-gnu/libc.so.6(pthread_mutex_lock+0x36)[0xf728cd76]/usr/bin/tor(tor_mutex_acquire+0x2c)[0xf77220cc]
After manually starting the tor service again, killing tor-launcher, and
manually starting /usr/local/sbin/tails-tor-launcher from a root
terminal, Tor bootstraps successfully.
anonym, may you please have a look? It might be related to e.g. #7283 (closed)
or another crazy trick of ours, that perhaps is not needed with Tor
0.2.6 anymore?
Actually, Tor Launcher seems to have nothing to do with this. This fixes
it for me:
--- a/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/10-tor.sh+++ b/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/10-tor.sh@@ -49,7 +49,6 @@ if [ "$(tails_netconf)" = "obstacle" ]; then # when no bridge is used the severity is "warn". tordate/20-time.sh # depends on grepping these error messages, so we temporarily # increase Tor's logging severity.- tor_control_setconf "Log=\"info file ${TOR_LOG}\"" /usr/local/sbin/tails-tor-launcher & fi
Indeed, any try to SETCONF Log=... makes Tor segfault, and I’ve
verified that it’s not our shell library that’s broken by doing it all
manually with netcat (which of course ends up being equivalent, oh
well). Actually, SETCONF Log is enough to make Tor go boom. Note that
it doesn’t matter if we are using bridge mode. Also note that this
doesn’t affect Vidalia’s logging facility since it’s using the event
listener, and not SETCONF Log in any way.
In other news, I pushed commit 37f7e24 (and a small fixup in commit
53ce7cd), which removes our in-tree Tor Launcher and makes us use the
Tor Browser’s bundled Tor Launcher, which will fix #7283 (closed).
Wow, already fixed! So in the next Tor rc we’ll be able to test all
time syncing stuff. Currently this bug prevents us from testing it with
bridges, since the SETCONF Log=... thing we get the segfault from is
related to that.
I see 6a6093e added in that branch. Let’s say it’s fine, even if
unrelated, because we’ll merge this branch soonish. However, it brings
one undocumented change, that is replacing --app with -?-app in the
regexp. Why is that? If you can do it really soon, please rewrite the
branch’s history so that this change is in its own commit, that explains
why we need it.
Also, shall I merge this branch into experimental, or is it too early in
your opinion?
Once we’ve made up our mind on these points, I’ll close this ticket as
resolved, and the follow-ups will be tracked by #7934 (closed).
I see 6a6093e added in that branch. Let’s say it’s fine, even
if unrelated, because we’ll merge this branch soonish. However, it
brings one undocumented change, that is replacing --app with -?-app
in the regexp. Why is that? If you can do it really soon, please rewrite
the branch’s history so that this change is in its own commit, that
explains why we need it.
Firefox accepts both single and double dash for its options. Here we
used to grep for double dash only, but apparently we start Tor Launcher
using single dash. So the Tor Launcher killing code is broken twice
over. But, yeah, this is unrelated to this branch, and I’m unsure why I
pushed it here since it’s a regression and should be fixed in 1.3.1.
Created #9067 (closed) + new branch with this commit (and updated commit
message).
Would you mind if I dropped the commit from this branch to reduce the
Git pollution?
Also, shall I merge this branch into experimental, or is it too early
in your opinion?
At least wait until my question about dropping the commit is resolved.
Would you mind if I dropped the commit from this branch to reduce
the Git pollution?
Please do so, if you can do it, say, within 72 hours :)
Done.
I tried to merge it into experimental, but he APT level merge
(tails-merge-suite feature-8925-tor-0.2.6 experimental) failed:
basename: missing operandTry 'basename --help' for more information.Error: Too few arguments for command 'copy'!Syntax: reprepro [-C <component> ] [-A <architecture>] [-T <packagetype>] copy <destination-distribution> <source-distribution> <package-names to pull>There have been errors!xargs: reprepro: exited with status 255; aborting
> basename: missing operand> Try 'basename --help' for more information.> Error: Too few arguments for command 'copy'!> Syntax: reprepro [-C <component> ] [-A <architecture>] [-T <packagetype>] copy> <destination-distribution> <source-distribution> <package-names to pull>> There have been errors!> xargs: reprepro: exited with status 255; aborting>
Seems like tails-merge-suite should not try to merge an empty suite into
anything.
Please file a low prio bug if you can be bothered to.