Opened 8 years ago

Last modified 8 years ago

#7146 enhancement new

optionally suppress the warning message from twistd if process is already running

Reported by: zooko Owned by:
Priority: normal Milestone:
Component: runner Keywords:
Cc: Branch:
Author:

Description

We Tahoe-LAFS folks are working with the git-annex hacker (Joey Hess) to make Tahoe-LAFS a first-class backend for git-annex. JoeyH has two changes he would like to see in Tahoe-LAFS. One of them is that he doesn't like the fact that it emits noisy warnings when git-annex invokes tahoe --quiet start, if the tahoe process is already running. Here is the ticket on the Tahoe-LAFS trac:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2149

The best way to fix this from our perspective would be if twistd would allow us to pass it an option asking it to start the process if the process is not already started, and to stay quiet about it if the process is already started.

Change History (4)

comment:1 Changed 8 years ago by zooko

If any Twisted devs could indicate to me whether a patch that makes this change would be considered, then I might be willing to write such a patch. Or other folks who care about Tahoe-LAFS and/or git-annex might.

comment:2 Changed 8 years ago by Jean-Paul Calderone

I think you're talking about this message:

Another twistd server is running, PID NNNNN

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.

But presumably any message from twistd is going to cause problems (those problems being that git-annex gets confused and dies, I guess? You didn't say, you just said "doesn't like").

Are you suggesting a flag that turns off this message or a flag that turns off all messages from twistd? How will error reporting work once all messages are turned off?

What about just sending the messages to stderr instead?

What about messages emitted by the Python runtime or standard library (or third-party) modules used by twistd? My personal experience suggests it's actually extremely difficult to convince a Python program to be stdout-clean due to the large amount of code beyond any single project's control that generally doesn't respect stdout as a place for structured data.

comment:3 in reply to:  2 Changed 8 years ago by zooko

Replying to exarkun:

I think you're talking about this message:

Another twistd server is running, PID NNNNN

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.

Yes, that's the one.

But presumably any message from twistd is going to cause problems (those problems being that git-annex gets confused and dies, I guess? You didn't say, you just said "doesn't like").

No, I think the problem is just that the user doesn't like seeing this message, but I'm not sure. I'll ask Joey Hess (author of git-annex, which is using Tahoe-LAFS) to comment.

Are you suggesting a flag that turns off this message or a flag that turns off all messages from twistd? How will error reporting work once all messages are turned off?

No, this ticket is just about the particular message that emits when start is issued when the process is already started. That's because what the user (git-annex) really wants a tahoe make-sure-it-is-running, and he's using tahoe start for that. So an alternate solution to his issue would be to add a tahoe make-sure-it-is-started instead of a --quiet flag that could be passed to tahoe start.

What about just sending the messages to stderr instead?

Seems like always a good idea, orthogonal to the other ideas in this ticket.

What about messages emitted by the Python runtime or standard library (or third-party) modules used by twistd? My personal experience suggests it's actually extremely difficult to convince a Python program to be stdout-clean due to the large amount of code beyond any single project's control that generally doesn't respect stdout as a place for structured data.

I think that's a separate issue.

comment:4 Changed 8 years ago by Joey Hess

Yes, this is only a cosmetic issue, extraneous stdout/stderr doesn't cause any problems other than looking very ugly to the user in this particular use case of git-annex and tahoe.

(Currently traveling and may have several days latency on any followups.)

Note: See TracTickets for help on using tickets.