mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 20:33:31 +01:00
Move call to event_init() immediately after start_daemon(); move start_daemon earlier. This should fix using libevent with RunAsDaemon.
svn:r3354
This commit is contained in:
parent
0aff4ff4cb
commit
a38bccdca7
@ -245,6 +245,18 @@ int
|
||||
options_act(void) {
|
||||
struct config_line_t *cl;
|
||||
or_options_t *options = get_options();
|
||||
static int libevent_initialized = 0;
|
||||
|
||||
/* XXXX009 We once had a reason to separate start_daemon and finish_daemon:
|
||||
* It let us have the parent process stick around until we were sure Tor
|
||||
* was started. Should we make start_daemon get called earlier? -NM */
|
||||
if (options->RunAsDaemon) {
|
||||
start_daemon(options->DataDirectory);
|
||||
}
|
||||
if (!libevent_initialized) {
|
||||
event_init();
|
||||
libevent_initialized = 1;
|
||||
}
|
||||
|
||||
clear_trusted_dir_servers();
|
||||
for (cl = options->DirServers; cl; cl = cl->next) {
|
||||
@ -302,13 +314,6 @@ options_act(void) {
|
||||
|
||||
/* Start backgrounding the process, if requested. */
|
||||
|
||||
/* XXXX009 We once had a reason to separate start_daemon and finish_daemon:
|
||||
* It let us have the parent process stick around until we were sure Tor
|
||||
* was started. Should we make start_daemon get called earlier? -NM */
|
||||
if (options->RunAsDaemon) {
|
||||
start_daemon(options->DataDirectory);
|
||||
}
|
||||
|
||||
/* Finish backgrounding the process */
|
||||
if (options->RunAsDaemon) {
|
||||
/* We may be calling this for the n'th time (on SIGHUP), but it's safe. */
|
||||
|
@ -1241,8 +1241,6 @@ static int tor_init(int argc, char *argv[]) {
|
||||
return -1;
|
||||
}
|
||||
atexit(exit_function);
|
||||
event_init(); /* This needs to happen before net stuff. Is it okay if this
|
||||
* happens before daemonizing? */
|
||||
|
||||
if (init_from_config(argc,argv) < 0) {
|
||||
log_fn(LOG_ERR,"Reading config failed--see warnings above. For usage, try -h.");
|
||||
|
Loading…
Reference in New Issue
Block a user