"tahoe start" emits an error message when tahoe is already running #2149

New issue

Closed

opened 2014-01-08 23:19:02 +00:00 by zooko · 18 comments

zooko commented

2014-01-08 23:19:02 +00:00

In #2146, joeyh reports that there is a problem with git-annex's use of tahoe-lafs, which is that when git-annex invokes tahoe start, then if the tahoe process is already running, tahoe start emits some error messages on stderr:

joey@darkstar:~/tmp/r>git annex get file
get file (from tahoe...) STARTING '/home/joey/.tahoe/git-annex/ba05f2d7-a100-4ffe-bd82-d2da70f94313'
Another twistd server is running, PID 26595

This could either be a previously started instance of your application or a
different application entirely. To start a new one, either run it in some other
directory, or use the --pidfile and --logfile parameters to avoid clashes.

URI:LIT:k5swiickmfxcaibyeaytkorrgq5dembajjcvgvbagiydcnak retrieved and written to /home/joey/tmp/r/.git/annex/tmp/SHA256E-s30--ae5d0003efb0749a6754b410b91ff25a5de68f76ff72b409e0e6ca0236378734
ok
(Recording state in git...)

git-annex doesn't want to ignore messages sent to stderr, so instead it would like for tahoe start not to complain about an already-started process.

In #2146, joeyh reports that there is a problem with git-annex's use of tahoe-lafs, which is that when git-annex invokes `tahoe start`, then if the tahoe process is already running, `tahoe start` emits some error messages on stderr: ``` joey@darkstar:~/tmp/r>git annex get file get file (from tahoe...) STARTING '/home/joey/.tahoe/git-annex/ba05f2d7-a100-4ffe-bd82-d2da70f94313' Another twistd server is running, PID 26595 This could either be a previously started instance of your application or a different application entirely. To start a new one, either run it in some other directory, or use the --pidfile and --logfile parameters to avoid clashes. URI:LIT:k5swiickmfxcaibyeaytkorrgq5dembajjcvgvbagiydcnak retrieved and written to /home/joey/tmp/r/.git/annex/tmp/SHA256E-s30--ae5d0003efb0749a6754b410b91ff25a5de68f76ff72b409e0e6ca0236378734 ok (Recording state in git...) ``` git-annex doesn't want to ignore messages sent to stderr, so instead it would like for `tahoe start` not to complain about an already-started process.

zooko added the

labels 2014-01-08 23:19:02 +00:00

zooko added this to the undecided milestone 2014-01-08 23:19:02 +00:00

daira was assigned by zooko

2014-01-08 23:19:02 +00:00

zooko commented

2014-01-08 23:19:31 +00:00

Author

I propose that if a process is already running then tahoe start should emit a non-error (i.e. non-complainy-sounding) message, on stdout instead of on stderr, saying something like "Note: a tahoe process linked to the node directory was already running, so doing nothing.".

joeyh: would this be satisfactory for git-annex's purposes?

I propose that if a process is already running then `tahoe start` should emit a non-error (i.e. non-complainy-sounding) message, on stdout instead of on stderr, saying something like "Note: a tahoe process linked to the node directory was already running, so doing nothing.". joeyh: would this be satisfactory for git-annex's purposes?

zooko added

c/code-nodeadmin

and removed

c/unknown

labels 2014-01-08 23:19:31 +00:00

gdt commented

2014-01-08 23:23:16 +00:00

Owner

This strikes me as messing up normal behavior to accomodate a broken caller. starting a process (of which there can be only one) when it is already running is actually an error. So there could be a "ensure-running" command that does start if it isn't running, and git-annex could use that. Or there could be some "status" command that returns 0 if tahoe is running and 1 if not, and git-annex could do that and start if necessary.

zooko commented

2014-01-08 23:24:36 +00:00

Author

Replying to gdt:

This strikes me as messing up normal behavior to accomodate a broken caller. starting a process (of which there can be only one) when it is already running is actually an error.

I disagree. There is no requirement for the caller to refrain from calling tahoe start when the process is already running. The recommended way to ensure that a process is running is to call tahoe start. Why should it be otherwise?

Replying to [gdt](/tahoe-lafs/trac/issues/2149#issuecomment-396148): > This strikes me as messing up normal behavior to accomodate a broken caller. starting a process (of which there can be only one) when it is already running is actually an error. I disagree. There is no requirement for the caller to refrain from calling `tahoe start` when the process is already running. The recommended way to ensure that a process is running is to call `tahoe start`. Why should it be otherwise?

gdt commented

2014-01-08 23:28:51 +00:00

Owner

The point of start when started being an error is to allow detecting incorrect assumptions. I expected this behavior because most other things behave this way - starting daemons by hand, and NetBSD's /etc/rc.d system, in which start and stop are errors if the program is or is not running. So I propose ensure-start and ensure-stop, which are non-erroring versions of start and stop, and which do not output anything if there is nothing to be done, and which do not write to stderr if there is no error.

zooko commented

2014-01-08 23:47:48 +00:00

Author

I cannot think of any case that I can recall where that information was useful to a caller. "Start if it is not already running" is what I think most users want, and "Start if it is not already running, and give me an error message if it was already running" is not something I've seen used in practice.

I guess that would be useful for situations where it was important to the caller that the thing was previously not-running — so important that the caller needs to do something about it. Do what? Kill the running process? Call a human for help? If it finds out that the process was already running. When would you want to do that about a tahoe-lafs process?

Now, I do think it can be useful if the caller is a human using the command-line, to get a visual indicator of whether the process was just started in response to my manual entry of tahoe start or was already running. But for me as a human operator, neither of those things is an error, and they should be displayed on stdout as normal messages like "Started…" or "Already running…", and the exit code should be set to indicate success in both cases.

Okay, I guess I consider "do things like other similar daemons do" to be a pretty good reason. However, I must say I have no often observed cases where writing an error message and setting an exit code when you find the thing running was helpful. I cannot think of any case that I can recall where that information was useful to a caller. "Start if it is not already running" is what I think most users want, and "Start if it is not already running, and give me an error message if it was already running" is not something I've seen used in practice. I guess that would be useful for situations where it was important to the caller that the thing was previously not-running — so important that the caller needs to do something about it. Do what? Kill the running process? Call a human for help? If it finds out that the process was already running. When would you want to do that about a tahoe-lafs process? Now, I *do* think it can be useful if the caller is a human using the command-line, to get a visual indicator of whether the process was just started in response to my manual entry of `tahoe start` or was already running. But for me as a human operator, neither of those things is an error, and they should be displayed on stdout as normal messages like "Started…" or "Already running…", and the exit code should be set to indicate success in both cases.

zooko commented

2014-01-08 23:49:19 +00:00

Author

This is one of two issues blocking the git-annex↔LAFS integration, as mentioned here: http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=85272d8a988b249d755ac3f8133e2bf8126fb271 . The other is #2147.

This is one of two issues blocking the git-annex↔LAFS integration, as mentioned here: <http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=85272d8a988b249d755ac3f8133e2bf8126fb271> . The other is #2147.

joeyh commented

2014-01-08 23:52:09 +00:00

Owner

tahoe start info message on stdout would be ok, especially if --quiet suppressed it

ensure-start would also be ok

tahoe start info message on stdout would be ok, especially if --quiet suppressed it ensure-start would also be ok

daira commented

2014-04-01 00:30:10 +00:00

Shouldn't git annex be running tahoe restart, not tahoe start? It is correct for tahoe start to give an error if already running, and for tahoe restart to succeed whether or not Tahoe was already running.

Shouldn't git annex be running `tahoe restart`, not `tahoe start`? It is correct for `tahoe start ` to give an error if already running, and for `tahoe restart` to succeed whether or not Tahoe was already running.

joeyh commented

2014-04-01 00:49:06 +00:00

Owner

tahoe restart bounces the server. I don't want git-annex to do that every time it tries to access it. I just want git-annex to start the server if it's not already running.

joeyh commented

2014-04-01 01:00:25 +00:00

Owner

This doesn't technically block the git-annex integration. git-annex works fine, it just scares users with this ugly message every time it tries to use tahoe.

daira modified the milestone from undecided to 1.12.0

2014-04-02 16:10:26 +00:00

daira commented

2014-04-03 00:21:14 +00:00

Replying to joeyh:

tahoe restart bounces the server. I don't want git-annex to do that every time it tries to access it. I just want git-annex to start the server if it's not already running.

You're right, so we should add tahoe --quiet start. (-q/--quiet is already a global option, so it goes before the command name.)

Replying to [joeyh](/tahoe-lafs/trac/issues/2149#issuecomment-396155): > tahoe restart bounces the server. I don't want git-annex to do that every time it tries to access it. I just want git-annex to start the server if it's not already running. You're right, so we should add `tahoe --quiet start`. (`-q`/`--quiet` is already a global option, so it goes before the command name.)

daira commented

2014-04-03 00:27:07 +00:00

Note that it is actually twistd that is emitting the error message. We can redirect stderr before passing control to twistd.run(), but that would redirect all error messages, not just the "Another twistd server is running" one.

Note that it is actually `twistd` that is emitting the error message. We can redirect stderr before passing control to `twistd.run()`, but that would redirect *all* error messages, not just the "Another twistd server is running" one.

daira commented

2014-04-03 00:28:19 +00:00

... and there isn't any "don't complain if already running" option to twistd.

... and there isn't any "don't complain if already running" option to `twistd`.

zooko commented

2014-04-14 23:49:36 +00:00

Author

I opened a ticket for Twisted: https://twistedmatrix.com/trac/ticket/7146

I opened a ticket for Twisted: <https://twistedmatrix.com/trac/ticket/7146>

warner commented

2016-03-22 05:02:25 +00:00

Milestone renamed

warner modified the milestone from 1.12.0 to 1.13.0

2016-03-22 05:02:25 +00:00

warner commented

2016-06-28 18:17:14 +00:00

renaming milestone

warner modified the milestone from 1.13.0 to 1.14.0

2016-06-28 18:17:14 +00:00

Brian Warner <warner@lothar.com> commented

2017-09-19 17:20:49 +00:00

Owner

In 04b34b6/trunk:

Merge PR417: rewrite tahoe start/stop/daemonize

* refs ticket:1148 (splits up startstop_node, improves coverage)
* refs ticket:275 ('start' probably doesn't exit until furl is written)
* refs ticket:1121 (probably improves coverage)
* refs ticket:1377 (probably fixed)
* refs ticket:2149 (might influence, probably won't fix)
* refs ticket:719 (probably improved)

In [04b34b6/trunk](/tahoe-lafs/trac/commit/04b34b6fd2bb112942d2cb8ea41ef11ee4c72347): ``` Merge PR417: rewrite tahoe start/stop/daemonize * refs ticket:1148 (splits up startstop_node, improves coverage) * refs ticket:275 ('start' probably doesn't exit until furl is written) * refs ticket:1121 (probably improves coverage) * refs ticket:1377 (probably fixed) * refs ticket:2149 (might influence, probably won't fix) * refs ticket:719 (probably improved) ```