[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