'tahoe run' should not fail silently #355

New Issue

tahoe-lafs · 2008-03-16T00:56:33Z

drewp commented

2008-03-16 00:56:33 +00:00

I use supervisord, so I'd like to run tahoe in the foreground.

tahoe-lafs added the

labels 2008-03-16 00:56:33 +00:00

tahoe-lafs added this to the eventually milestone 2008-03-16 00:56:33 +00:00

warner was assigned by tahoe-lafs

2008-03-16 00:56:33 +00:00

warner commented

2008-03-17 20:06:38 +00:00

'tahoe start BASEDIR' is really just a wrapper around 'cd BASEDIR; twistd -y *.tac', so you could have supervisord run 'twistd --nodaemon -y foo.tac', and that would leave it in the foreground.

We could also add a --nodaemon option to 'tahoe start', although in that case I'd be tempted to call it 'tahoe run' instead.

'tahoe start BASEDIR' is really just a wrapper around 'cd BASEDIR; twistd -y *.tac', so you could have supervisord run 'twistd --nodaemon -y foo.tac', and that would leave it in the foreground. We could also add a --nodaemon option to 'tahoe start', although in that case I'd be tempted to call it 'tahoe run' instead.

drewp commented

2008-03-19 03:03:04 +00:00

I see 'tahoe run' is already there, and I'm sorry I missed that before.

But, I have some usability complaints about 'tahoe run':

Simply running 'tahoe run' silently exits with status 1. Nothing is written to console nor ~/.tahoe/logs/twistd.log. Note that I have only a partial ~/.tahoe, since my real instance is somewhere else.
I deliberately tried running in the correct root while my daemonized tahoe was already going, to see what would happen. The result is that "Couldn't listen on any:34279: (98, 'Address already in use')" goes to INSTANCE/logs/tahoesvc.log and then the reactor keeps running. I wish it would write that kind of startup error to the console and then exit 1.

I see 'tahoe run' is already there, and I'm sorry I missed that before. But, I have some usability complaints about 'tahoe run': 1. Simply running 'tahoe run' silently exits with status 1. Nothing is written to console nor ~/.tahoe/logs/twistd.log. Note that I have only a partial ~/.tahoe, since my real instance is somewhere else. 2. I deliberately tried running in the correct root while my daemonized tahoe was already going, to see what would happen. The result is that "Couldn't listen on any:34279: (98, 'Address already in use')" goes to INSTANCE/logs/tahoesvc.log and then the reactor keeps running. I wish it would write that kind of startup error to the console and then exit 1.

zooko commented

2008-03-20 17:45:18 +00:00

I guess you missed the existence of tahoe run because it isn't mentioned in docs/running.html. Perhaps we should change that document to describe tahoe run instead of tahoe start? (That document is intended for the beginner, who might prefer the simplicity of tahoe run.)

Something else that might help is if the output of tahoe --help separated node control (start, stop, restart, run, create-client, create-introducer) from filesystem usage (put, get, rm, etc.)

Drew: as someone with "fresh eyes", what do you think about these two proposed changes?

I guess you missed the existence of `tahoe run` because it isn't mentioned in [docs/running.html](http://allmydata.org/source/tahoe/trunk/docs/running.html). Perhaps we should change that document to describe `tahoe run` instead of `tahoe start`? (That document is intended for the beginner, who might prefer the simplicity of `tahoe run`.) Something else that might help is if the output of `tahoe --help` separated node control (`start`, `stop`, `restart`, `run`, `create-client`, `create-introducer`) from filesystem usage (`put`, `get`, `rm`, etc.) Drew: as someone with "fresh eyes", what do you think about these two proposed changes?

warner commented

2008-03-20 19:52:24 +00:00

Heh, it probably says something about the documentation when the author of a command forgets about its existence :). Oops.

The ~/.tahoe/ directory is meant to be useable as either a complete Tahoe node (which is why 'tahoe create-client' and 'tahoe start' default to using it) or as a pointer to the URL at which your real node lives (i.e. the 'tahoe ls' command looks in ~/.tahoe/node.url for a starting point).

I need to think more about the startup problems that you hit. Maybe we need a 'chdir' into the target directory in src/allmydata/scripts/startstop_node.py:run().

Heh, it probably says something about the documentation when the author of a command forgets about its existence :). Oops. The ~/.tahoe/ directory is meant to be useable as either a complete Tahoe node (which is why 'tahoe create-client' and 'tahoe start' default to using it) or as a pointer to the URL at which your real node lives (i.e. the 'tahoe ls' command looks in ~/.tahoe/node.url for a starting point). I need to think more about the startup problems that you hit. Maybe we need a 'chdir' into the target directory in src/allmydata/scripts/startstop_node.py:run().

drewp commented

2008-03-26 06:31:40 +00:00

Separating the help into sections would be fine, but that's minor IMHO. It might also help to make start and run look more like peers:

start                  Start a node as a daemon.
run                    Run a node in the foreground.
stop                   Stop a node daemon.
restart                Restart a node.

In my case, I don't think I'll put a pointer in ~/.tahoe/node.url since I expect to be running at least two nodes all the time: the test grid and a production friendnet one. I'd rather have tahoe commands fail loudly when I fail to specify an instance directory (as opposed to sometimes accidentally operating on the wrong instance).

Anyway, the silent errors and hangs are much more important to me.

Separating the help into sections would be fine, but that's minor IMHO. It might also help to make start and run look more like peers: start Start a node as a daemon. run Run a node in the foreground. stop Stop a node daemon. restart Restart a node. In my case, I don't think I'll put a pointer in ~/.tahoe/node.url since I expect to be running at least two nodes all the time: the test grid and a production friendnet one. I'd rather have tahoe commands fail loudly when I fail to specify an instance directory (as opposed to sometimes accidentally operating on the wrong instance). Anyway, the silent errors and hangs are much more important to me.

davidsarah commented

2009-12-13 05:34:58 +00:00

Documentation improvements split into #856.

tahoe-lafs changed title from ~~run daemon in foreground~~ to 'tahoe run' should not fail silently

2009-12-13 05:34:58 +00:00

tahoe-lafs modified the milestone from eventually to 1.7.0

2010-02-02 03:11:26 +00:00

tahoe-lafs modified the milestone from 1.7.0 to soon

2010-06-12 22:55:59 +00:00

davidsarah commented

2010-08-08 01:28:35 +00:00

Replying to warner:

I need to think more about the startup problems that you hit. Maybe we need a 'chdir' into the target directory in src/allmydata/scripts/startstop_node.py:run().

The [current code does that]source:src/allmydata/scripts/startstop_node.py@4641#L212. I don't think that would have addressed the second point in comment:65421, though, or similar errors that occur on startup.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/355#issuecomment-65423): > I need to think more about the startup problems that you hit. Maybe we need a 'chdir' into the target directory in src/allmydata/scripts/startstop_node.py:run(). The [current code does that]source:src/allmydata/scripts/startstop_node.py@4641#L212. I don't think that would have addressed the second point in [comment:65421](/tahoe-lafs/trac-2024-07-25/issues/355#issuecomment-65421), though, or similar errors that occur on startup.

warner commented

2011-03-25 23:13:44 +00:00

It looks like this is part of the problem making #1360 fail silently (well, at least the "silent" part). Errors during startup are written to logs/tahoesvc.log, which is not where we usually expect them to go (normally I look in logs/twistd.log).

I think we could get rid of "tahoe run" and leave "tahoe start --nodaemon", or change the way "tahoe run" does logging so that any problems during startup get dumped to stderr (in addition to the logfile).

It looks like this is part of the problem making #1360 fail silently (well, at least the "silent" part). Errors during startup are written to logs/tahoesvc.log, which is not where we usually expect them to go (normally I look in logs/twistd.log). I think we could get rid of "tahoe run" and leave "tahoe start --nodaemon", or change the way "tahoe run" does logging so that any problems during startup get dumped to stderr (in addition to the logfile).

zooko commented

2011-03-26 01:59:56 +00:00

I'm still +1 in favor of eliminating tahoe run in favor of tahoe start --nodaemon.

I'm still +1 in favor of eliminating `tahoe run` in favor of `tahoe start --nodaemon`.

exarkun commented

2020-01-16 19:45:54 +00:00

"tahoe start" and the other daemonization commands are now deprecated (https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3273) and "tahoe run" will be the preferred and only way to run a tahoe node after that deprecation period ends.

"tahoe run" exits currently with code 1 when there is no runnable node in ~/.tahoe.
When "tahoe run" is used twice against the same node directory, the second attempt exits with code 1 and an error like "Another twistd server is running, PID ...".

"tahoe start" and the other daemonization commands are now deprecated (<https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3273>) and "tahoe run" will be the preferred and only way to run a tahoe node after that deprecation period ends. "tahoe run" exits currently with code 1 when there is no runnable node in ~/.tahoe. When "tahoe run" is used twice against the same node directory, the second attempt exits with code 1 and an error like "Another twistd server is running, PID ...".

exarkun added the

fixed

label 2020-01-16 19:45:54 +00:00

exarkun closed this issue

2020-01-16 19:45:54 +00:00

Sign in to join this conversation.