Opened 11 years ago

Closed 7 years ago

#2182 enhancement closed duplicate (duplicate)

process exit status support for Twisted

Reported by: synapsis Owned by: synapsis
Priority: normal Milestone:
Component: core Keywords:
Cc: manlio_perillo@…, Jean-Paul Calderone, jknight, itamarst, spiv, miracle2k Branch:
Author:

Description

This patch allows a twisted process to return a custom exit status.

The interface is simple (and compatible with current version of Twisted):

reactor.stop(exitStatus=0)

The current implementation simply return 1 when a signal is catched, and 2 when the application detects an error in the command line options.

Attachments (2)

exitstatus.patch (6.5 KB) - added by synapsis 11 years ago.
patch file for twisted
interfaces.patch (983 bytes) - added by synapsis 11 years ago.
patch file for twisted.internet.interfaces

Download all attachments as: .zip

Change History (14)

Changed 11 years ago by synapsis

Attachment: exitstatus.patch added

patch file for twisted

comment:1 Changed 11 years ago by Jean-Paul Calderone

Cc: Jean-Paul Calderone jknight itamarst added

Note #718 (of which this may be a duplicate) and #761.

This feature probably shouldn't be provided as an optional argument to reactor.stop, but as a feature of services, since services are what twistd deals with. For example, IProcess could have functions for getting and setting the desired exit code, which applications could invoke to communicate with twistd.

Changed 11 years ago by synapsis

Attachment: interfaces.patch added

patch file for twisted.internet.interfaces

comment:2 Changed 11 years ago by synapsis

I forgot to patch twisted.internet.interfaces.

With this ticket, the correct way to use the reactor is, as an example:

import sys from twisted.internet import reactor

# ...

sys.exit(reactor.run())

When using twistd and applications, this is all done behind the scenes

P.S.: I can't "compile" the docstrings, so I don't know if the syntax is correct

comment:3 in reply to:  1 Changed 11 years ago by synapsis

Replying to exarkun:

Note #718 (of which this may be a duplicate) and #761.

This feature probably shouldn't be provided as an optional argument to reactor.stop, but as a feature of services, since services are what twistd deals with. For example, IProcess could have functions for getting and setting the desired exit code, which applications could invoke to communicate with twistd.

I disagree.

Calling reactor.stop is the way to stop a twisted application, and this should be the equivalent of calling sys.exit.

The exit status management should go in the reactor, since this is the place where, as an example, signals are catched.

Adding a function for setting the desired exit code means to duplicate the action needed to stop a Twisted process.

Moreover adding a function to get the exit status does not make much sense to me, since the exit status is a property of the "closed process", not of the "running process".

This is just my opinion, of course.

comment:4 Changed 11 years ago by jknight

Having the exit status be the result of reactor.run(), as provided by reactor.stop() does seem like the most natural way to do it to me as well.

comment:5 Changed 11 years ago by spiv

Cc: spiv added

comment:6 in reply to:  4 Changed 11 years ago by Jean-Paul Calderone

Replying to jknight:

Having the exit status be the result of reactor.run(), as provided by reactor.stop() does seem like the most natural way to do it to me as well.

This doesn't provide any way to deal with #761, though. Any thoughts in that direction?

comment:7 Changed 11 years ago by jknight

reactor.run() can reraise KeyboardInterrupt after shutting down the reactor. twistd should catch this and cause the right exit code until python itself is fixed to exit with the appropriate exit code upon KeyboardInterrupt.

comment:8 in reply to:  7 Changed 11 years ago by synapsis

Replying to jknight:

reactor.run() can reraise KeyboardInterrupt after shutting down the reactor. twistd should catch this and cause the right exit code until python itself is fixed to exit with the appropriate exit code upon KeyboardInterrupt.

Why not to simply let the SIGINT handler set the exitStatus to SIGINT? Then it is under the responsibility of the application to do

sys.exit(reactor.run())

comment:9 Changed 11 years ago by jknight

Because you can't return such an exit status via exit. Signal exit codes are special. See other ticket for how to exit appropriately.

comment:10 Changed 11 years ago by Glyph

Owner: changed from Glyph to synapsis

comment:11 Changed 7 years ago by miracle2k

Cc: miracle2k added

comment:12 Changed 7 years ago by Jean-Paul Calderone

Resolution: duplicate
Status: newclosed

Duplicate of #718

Note: See TracTickets for help on using tickets.