'tahoe run' doesn't work for an introducer node #937

New Issue

tahoe-lafs · 2010-02-06T18:49:42Z

Bryan Larsen commented

2010-02-06 18:49:42 +00:00

I tried following the instructions (running.html) for creating an introducer, and it didn't work. With some help from secorp on IRC, we determined that I should use "tahoe start dirname" rather than "tahoe run". There's may be an underlying bug that should be fixed, but the install instructions should be fixed irregardless because people use the current install instructions on old versions.

This problem occurred with both 1.5 and 1.6

I tried following the instructions (running.html) for creating an introducer, and it didn't work. With some help from secorp on IRC, we determined that I should use "tahoe start dirname" rather than "tahoe run". There's may be an underlying bug that should be fixed, but the install instructions should be fixed irregardless because people use the current install instructions on old versions. This problem occurred with both 1.5 and 1.6

tahoe-lafs added the

labels 2010-02-06 18:49:42 +00:00

tahoe-lafs added this to the undecided milestone 2010-02-06 18:49:42 +00:00

Bryan Larsen commented

2010-02-06 18:51:24 +00:00

Attachment irclog.txt (5327 bytes) added

**Attachment** irclog.txt (5327 bytes) added

irclog.txt

5.2 KiB

zooko added

1.6.0

and removed

1.5.0

labels 2010-02-06 19:13:41 +00:00

zooko modified the milestone from undecided to 1.7.0

2010-02-06 19:13:41 +00:00

duck commented

2010-03-20 20:45:40 +00:00

Attachment 937_running.diff (783 bytes) added

Update of install instructions warning against using tahoe run for an introducer.

**Attachment** 937_running.diff (783 bytes) added Update of install instructions warning against using tahoe run for an introducer.

937_running.diff

783 B

tahoe-lafs added

code-frontend-cli

and removed

unknown

labels 2010-04-03 23:51:57 +00:00

tahoe-lafs changed title from ~~install instructions broken for creating an introducer node~~ to 'tahoe run' doesn't work for an introducer node, but is documented to work in running.html

2010-04-03 23:51:57 +00:00

davidsarah commented

2010-06-19 03:12:26 +00:00

running.html was corrected in changeset:8f3246430bc0a17b.

tahoe-lafs modified the milestone from 1.7.0 to soon

2010-06-19 03:12:26 +00:00

tahoe-lafs changed title from ~~'tahoe run' doesn't work for an introducer node, but is documented to work in running.html~~ to 'tahoe run' doesn't work for an introducer node

2010-06-19 03:12:26 +00:00

zooko commented

2010-06-19 04:29:08 +00:00

Attachment 937.dpatch.txt (55196 bytes) added

**Attachment** 937.dpatch.txt (55196 bytes) added

937.dpatch.txt

54 KiB

davidsarah commented

2010-06-19 05:27:20 +00:00

937.dpatch.txt was applied in changeset:49912c106e3dc3de.

davidsarah commented

2010-08-08 01:14:00 +00:00

changeset:a7c474a09893b9aa makes the error message more explicit, e.g.:

'<dir>' looks like it contains a non-client node (tahoe-introducer.tac).
Use 'tahoe start' instead of 'tahoe run'.

changeset:a7c474a09893b9aa makes the error message more explicit, e.g.: ``` '<dir>' looks like it contains a non-client node (tahoe-introducer.tac). Use 'tahoe start' instead of 'tahoe run'. ```

davidsarah commented

2010-08-08 01:20:46 +00:00

Oh, to debug why tahoe run doesn't work for an introducer (or key-generator or stats-gatherer), you'll now have to disable the check at source:src/allmydata/scripts/startstop_node.py@4641#L206.

Oh, to debug why `tahoe run` doesn't work for an introducer (or key-generator or stats-gatherer), you'll now have to disable the check at source:src/allmydata/scripts/startstop_node.py@4641#L206.

davidsarah commented

2012-05-21 00:15:13 +00:00

On #tahoe-lafs:

(00:26:41) makefu|EUER: hi, i am trying to run tahoe in the foreground to let supervisord handle startup. i found the magic line "tahoe run -C /path/to/dir" but when trying to start an introducer i get /path looks like it contains a non-client node (tahoe-introducer.tac).

(00:27:15) makefu|EUER: is there a way to keep tahoe in foreground even for the introducer?

On #tahoe-lafs: > (00:26:41) makefu|EUER: hi, i am trying to run tahoe in the foreground to let supervisord handle startup. i found the magic line "tahoe run -C /path/to/dir" but when trying to start an introducer i get `/path looks like it contains a non-client node (tahoe-introducer.tac).` > (00:27:15) makefu|EUER: is there a way to keep tahoe in foreground even for the introducer?

tahoe-lafs modified the milestone from soon to 1.11.0

2012-05-21 00:15:13 +00:00

davidsarah commented

2012-05-21 00:42:53 +00:00

This seems to be a workaround, assuming Twisted is installed system-wide (replace TAHOE_SOURCE_DIR and X as necessary):

cd to the introducer directory
export PYTHONPATH=TAHOE_SOURCE_DIR/support/lib/python2.X/site-packages
twistd --nodaemon -y tahoe-introducer.tac

This seems to be a workaround, assuming Twisted is installed system-wide (replace **TAHOE_SOURCE_DIR** and **X** as necessary): * cd to the introducer directory * export PYTHONPATH=**TAHOE_SOURCE_DIR**/support/lib/python2.**X**/site-packages * twistd --nodaemon -y tahoe-introducer.tac

warner commented

2012-05-21 05:45:49 +00:00

Attachment run-introducer.diff (3030 bytes) added

enable 'tahoe run' for introducer nodes

**Attachment** run-introducer.diff (3030 bytes) added enable 'tahoe run' for introducer nodes

run-introducer.diff

3.0 KiB

warner commented

2012-05-21 06:00:15 +00:00

that patch should enable "tahoe run" for both client and introducer
nodes. The specific issue was that "tahoe run" was hard-wired to load
client nodes only; it lacked the code to look at the .tac file (to find
out what kind of node was being started) and then load the appropriate
code.

I think we decided to switch away from .tac files a while ago (#1159), but only
"tahoe run" had made any steps in that direction (by hard-coding
client.Client instead of loading the .tac file). This moves us a
little bit closer. To avoid relying too much on .tac files, at least
upon their contents, both tahoe start and tahoe run must
decide what nodetype is being started (by looking at the name of the
.tac file, or perhaps from other clues): client, introducer,
key-generator, stats-gatherer, etc. Then it must load in the appropriate
class (client.Client, introducer.server.IntroducerNode,
etc), instantiate it, then start the instance.

This patch includes a test for the "emit a nice error message when asked
to 'tahoe run' a nodetype that we don't recognize", but it doesn't
include a test for normal success of 'tahoe run', since 'run' launches
the reactor, and that's not straightforward to do from within a unit
test. (note that we didn't previously have coverage of 'tahoe run'
either). I've run manual tests and things look ok.

We might consider changing 'tahoe run' to use the "twistd --nodaemon"
approach, which would make it look a lot closer to tahoe start.
However, that would make it more dependent upon .tac files, not less. In
the longer run, I think we should try the approach I came up with in my
[https://github.com/warner/toolbed/blob/master/toolbed/scripts/startstop.py "toolbed" project],
where I create a (in-memory) twistd plugin that creates the desired
Node, then set up the twistd arguments that will invoke this plugin,
then give control to twistd.runApp in a child process.

that patch should enable "tahoe run" for both client and introducer nodes. The specific issue was that "tahoe run" was hard-wired to load client nodes only; it lacked the code to look at the .tac file (to find out what kind of node was being started) and then load the appropriate code. I think we decided to switch away from .tac files a while ago (#1159), but only "tahoe run" had made any steps in that direction (by hard-coding `client.Client` instead of loading the .tac file). This moves us a little bit closer. To avoid relying too much on .tac files, at least upon their contents, both `tahoe start` and `tahoe run` must decide what nodetype is being started (by looking at the name of the .tac file, or perhaps from other clues): client, introducer, key-generator, stats-gatherer, etc. Then it must load in the appropriate class (`client.Client`, `introducer.server.IntroducerNode`, etc), instantiate it, then start the instance. This patch includes a test for the "emit a nice error message when asked to 'tahoe run' a nodetype that we don't recognize", but it doesn't include a test for normal success of 'tahoe run', since 'run' launches the reactor, and that's not straightforward to do from within a unit test. (note that we didn't previously have coverage of 'tahoe run' either). I've run manual tests and things look ok. We might consider changing 'tahoe run' to use the "`twistd --nodaemon`" approach, which would make it look a lot closer to `tahoe start`. However, that would make it more dependent upon .tac files, not less. In the longer run, I think we should try the approach I came up with in my [https://github.com/warner/toolbed/blob/master/toolbed/scripts/startstop.py "toolbed" project], where I create a (in-memory) twistd plugin that creates the desired Node, then set up the twistd arguments that will invoke this plugin, then give control to `twistd.runApp` in a child process.

davidsarah commented

2012-05-23 15:17:29 +00:00

Will review.

davidsarah commented

2012-05-23 15:20:57 +00:00

The other tac types are tahoe-key-generator.tac and tahoe-stats-gatherer.tac. Shall we support those while we're about it?

The other tac types are `tahoe-key-generator.tac` and `tahoe-stats-gatherer.tac`. Shall we support those while we're about it?

davidsarah commented

2012-05-23 15:30:57 +00:00

Replying to warner:

... (note that we didn't previously have coverage of 'tahoe run' either).

That's #1121.

We might consider changing 'tahoe run' to use the "twistd --nodaemon"
approach, which would make it look a lot closer to tahoe start.
However, that would make it more dependent upon .tac files, not less. In
the longer run, I think we should try the approach I came up with in my
"toolbed" project,
where I create a (in-memory) twistd plugin that creates the desired
Node, then set up the twistd arguments that will invoke this plugin,
then give control to twistd.runApp in a child process.

... or use the approach I suggested in ticket:1159#comment:-1 of using a .tac in the source tree. That solves the main version-skew problems with .tac files, and is possibly less disruptive to the existing code.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/937#issuecomment-75180): > ... (note that we didn't previously have coverage of 'tahoe run' either). That's #1121. > We might consider changing 'tahoe run' to use the "`twistd --nodaemon`" > approach, which would make it look a lot closer to `tahoe start`. > However, that would make it more dependent upon .tac files, not less. In > the longer run, I think we should try the approach I came up with in my > ["toolbed" project](https://github.com/warner/toolbed/blob/master/toolbed/scripts/startstop.py), > where I create a (in-memory) twistd plugin that creates the desired > Node, then set up the twistd arguments that will invoke this plugin, > then give control to `twistd.runApp` in a child process. ... or use the approach I suggested in ticket:1159#[comment:-1](/tahoe-lafs/trac-2024-07-25/issues/937#issuecomment--1) of using a `.tac` in the source tree. That solves the main version-skew problems with `.tac` files, and is possibly less disruptive to the existing code.

tahoe-lafs modified the milestone from 1.11.0 to 1.10.0

2012-05-23 15:45:27 +00:00

warner commented

2012-05-25 06:14:27 +00:00

(note, if we land my patch from #1159, then this one becomes moot)

(also, #1159 would handle key-generator and stats-gatherer too)

(note, if we land my patch from #1159, then this one becomes moot) (also, #1159 would handle key-generator and stats-gatherer too)

davidsarah commented

2013-01-31 15:51:55 +00:00

Will be fixed by #1159.

tahoe-lafs added the

duplicate