[Twisted-Python] supporting start/stop/restart behavior
Clark C. Evans
cce at clarkevans.com
Thu Mar 20 02:18:32 EST 2003
Thanks for responding, I know you're quite busy before PyCon.
On Wed, Mar 19, 2003 at 11:35:39PM -0600, Glyph Lefkowitz wrote:
| >... what [Twisted] misses, IMHO, is a simple interface to stop and
| You're right, but this is the wrong way to go about fixing it.
| > 1. Refactoring runApp to remove a hunk of code which
| > runs os.kill on a pid found in the given pidfile.
| > This is moved to another function, killApp, which
| > takes two arguments, config and signal. From the
| > runApp the code then calls killApp(config, signal=0)
| Currently, that code is there _only_ to determine, in a rather
| platform-specific way, whether the server should attempt to keep
| starting or not. It's not a generalized stop-the-application.
If twistd adds (in a "rather platform-specific" way) support for
stop and restart, then I'm sure platform-specific linkages can be
added later on; for example doing NT based service API calls
instead of fork / pidfiles / signals.
| > c. if stop or restart are chosen, then this kills the
| > current process using the given pidfile (which defaults
| > to twistd.pid in the current directory) through
| > killApp(signal=SIGTERM)
| Why put this into Twisted where we have to swaddle it in a layer of
| cross-platform compatibility rather than just letting the user use
| whatever tools are available on their system for interacting with
Why not? With twistd, Twisted is taking on responsibility for
'starting' an application, shouldn't it finish the job with
stop and restart?
| So you are trying to solve a documentation problem by adding
| functionality to a different place, necessitating more documentation?
Got me. ;)
| We write these frameworks in Python, but I agree with this point:
| none of this daemon/logging/startup/shutdown behavior needs to
| be in an application.
Cool. Does it belong in a framework? If not, where?
| My view on functionality like this is that it is a platform-specific
| thing. Even assuming that signals worked like you expect them to
| across all platforms that we are trying to support, there are other
| issues. What about the cultural expectation of command lines? On
| win32, the way Python programs are run isn't very natural. On the
| command line, the location of the .exe is significant, there's no such
| thing as a shebang line, and users aren't accustomed to running
| interpreters on scripts. They expect to have an icon to click on,
| usually a Service. There are also differing cultural expectations of
| how you run stuff like this on MacOS. Does the start/stop thing have a
| GUI? A monitoring icon in the dock?
| Now, we don't *currently* have functionality like that, but we hope to
| one day. I am beginning to despair of ever actually achieving that
| goal, though, since nobody who understands it has time, and so many
| other programmers have habits that are opposed to this approach...
All of this is great. But I've got many applications that I am
writing, and would like to write; and I'd like a nice way to
start, stop, and restart my twisted daemons. Currently, "twistd"
seems to be the preferred command line approach.
| Supporting mechanisms in the framework that make configuration and
| introspection impossible without editing the start-up code for your
| particular application would make this eventual goal even more
| difficult than it already is.
| Components written for twisted should be written in such a way that
| they can be loaded into existing applications without running a script.
Uncle! Uncle! Ok. Ok. '__main__' == __name__ is bad.
| If you want to improve twistd, please feel free to suggest ways that
| stopping/restarting could be made easier or even more consistent across
| platforms. For example, "killApp" might make sense if, on
| signals-challenged platforms, twistd automatically opened a
| localhost-only socket which allowed communication with the server.
Ok. Could we add to twistd 'start', 'stop' and 'restart' sub-commands,
with 'start' being the default. For now, we implement stop with kill
signals. When we get time we refactor the whole start/stop/restart code
so that it uses a 'Process' object that is platform specific. The
process object has 'start', 'stop', and 'restart' methods, and it has
two or more implementations, including, but not limited to a
UnixProcess, which uses kill/signals/pidfile, and a NT Process, which
uses NT services, etc.
As for GUIs. What would be useful is one more sub-command, 'query'.
Which returns a status of the given process, 'starting', 'stopping',
'running', 'restarting', 'stopped'. With those in place, I'm sure
someone could write a nice cross-platform wxWindows viewer which calls
twistd to check the status of various processes, etc. We'd probably
at that point also have to start thinking about registry entries,
i.e. configuration settings (Coca?).
More information about the Twisted-Python