[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-relays] serious gap in 'chroot' documentation
At 23:13 10/16/2013 -0400, starlight.2013q4@xxxxxxxxxxx wrote:
>Newer versions of 'openssl' require access to
>
> /proc/sys/kernel/random
>
Got this wrong, in part due to the difficulty
of debugging 'chroot'.
'libevent' does make use of /proc/sys/kernel/random/uuid
if it's available but tolerates a failed open()
and uses /dev/urandom in any case. Saw it in 'strace'
and mistook this for the problem.
What was missing was
libgcc_s.so.1
which is documented as needed for CentOS
but with no specific comment as to why.
'libgcc' is used by 'libpthreads' but is not
kept loaded. Is dynamically loaded
when 'pthread_exit()' is called during
'tor' reload operations and then unloaded.
A way to test this is to SIGHUP 'tor'.
So a minimalist does not see 'libgcc' in
the 'lsof' for 'tor', which starts fine
without it, and thinks it unnecessary.
What's painful is the week-long interval
before 'tor' crashes with SIGABORT.
The error written to stderr
libgcc_s.so.1 must be installed for pthread_cancel to work
is lost since fd 2 goes to /dev/null
by default when 'tor' runs as a daemon.
Suggest a comment about this be added to the
'chroot' documentation page, including
that it's a good idea to test the 'chroot'
setup with a
pkill -HUP tor
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays