#2149 closed enhancement (wontfix)

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

Reported by: zooko Owned by: daira
Priority: normal Milestone: 1.14.0
Component: code-nodeadmin Version: 1.10.0
Keywords: usability error cli Cc:
Launchpad Bug:


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
(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.

Change History (21)

comment:1 Changed at 2014-01-08T23:19:31Z by zooko

  • Component changed from unknown to code-nodeadmin
  • Owner changed from daira to joeyh

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?

comment:2 Changed at 2014-01-08T23:19:39Z by zooko

  • Keywords usability error added

comment:3 Changed at 2014-01-08T23:19:45Z by zooko

  • Keywords cli added

comment:4 follow-up: Changed at 2014-01-08T23:23:16Z by 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. 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.

comment:5 in reply to: ↑ 4 Changed at 2014-01-08T23:24:36Z by zooko

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?

comment:6 follow-up: Changed at 2014-01-08T23:28:51Z by gdt

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.

comment:7 in reply to: ↑ 6 Changed at 2014-01-08T23:47:48Z by zooko

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.

comment:8 Changed at 2014-01-08T23:49:19Z by zooko

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.

comment:9 Changed at 2014-01-08T23:52:09Z by joeyh

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

ensure-start would also be ok

comment:10 Changed at 2014-04-01T00:30:10Z by daira

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.

Last edited at 2014-04-01T00:30:23Z by daira (previous) (diff)

comment:11 follow-up: Changed at 2014-04-01T00:49:06Z by 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.

comment:12 Changed at 2014-04-01T01:00:25Z by joeyh

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.

comment:13 Changed at 2014-04-02T16:10:26Z by daira

  • Milestone changed from undecided to 1.12.0
  • Owner changed from joeyh to daira
  • Status changed from new to assigned

comment:14 in reply to: ↑ 11 Changed at 2014-04-03T00:21:14Z by daira

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.)

comment:15 Changed at 2014-04-03T00:27:07Z by daira

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.

comment:16 Changed at 2014-04-03T00:28:19Z by daira

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

comment:17 Changed at 2014-04-14T23:49:36Z by zooko

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

comment:18 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:19 Changed at 2016-06-28T18:17:14Z by warner

  • Milestone changed from 1.13.0 to 1.14.0

renaming milestone

comment:20 Changed at 2017-09-19T17:20:49Z by Brian Warner <warner@…>

In 04b34b6/trunk:

Merge PR417: rewrite tahoe start/stop/daemonize

comment:21 Changed at 2020-01-20T20:38:27Z by exarkun

  • Resolution set to wontfix
  • Status changed from assigned to closed

"tahoe start" is now deprecated.

Note: See TracTickets for help on using tickets.