Prev: announcing jsonutil package
Next: how to convert a sudsobject into its representative XML?
From: mk on 18 Jun 2010 13:47
Hello everyone,

I'm starting a SocketServer.TCPServer in my program, but since I want to
report problems to script starting the program, I want to go daemon
*after* TCPServer has done binding to port.

Is this likely to cause problems? I mean, my client works when I do the
above, that is, it connects to the server. But I'm not sure if above is
the Right Thing(tm).

First:

self.server = SocketServer.TCPServer((host, port), handleclass,
bind_and_activate=False)
self.server.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
self.server.server_bind()
self.server.server_activate()

(except etc skipped for brevity)

Second:

def daemonize(self):
try:
pid = os.fork()
except OSError, e:
print 'failed to fork:', str(e)
os._exit(1)
# if pid is non-zero, we're in parent
if pid:
os._exit(0)
os.setsid()
os.chdir(globalpath)
os.umask(0)




Regards,
mk

From: Ben Finney on 20 Jun 2010 06:00
mk <mrkafk(a)gmail.com> writes:

> I'm starting a SocketServer.TCPServer in my program, but since I want
> to report problems to script starting the program, I want to go daemon
> *after* TCPServer has done binding to port.
>
> Is this likely to cause problems? I mean, my client works when I do
> the above, that is, it connects to the server. But I'm not sure if
> above is the Right Thing(tm).

There is more to becoming a well-behaved daeon process than merely
detaching the process. For details, see PEP 3143 “Standard daemon
process library” <URL:http://www.python.org/dev/peps/pep-3143/>.

--
\ “Life does not cease to be funny when people die any more than |
`\ it ceases to be serious when people laugh.” —George Bernard Shaw |
_o__) |
Ben Finney
From: Nobody on 20 Jun 2010 09:30
On Sun, 20 Jun 2010 20:00:14 +1000, Ben Finney wrote:

>> I'm starting a SocketServer.TCPServer in my program, but since I want
>> to report problems to script starting the program, I want to go daemon
>> *after* TCPServer has done binding to port.
>>
>> Is this likely to cause problems? I mean, my client works when I do
>> the above, that is, it connects to the server. But I'm not sure if
>> above is the Right Thing(tm).
>
> There is more to becoming a well-behaved daeon process than merely
> detaching the process. For details, see PEP 3143 “Standard daemon
> process library” <URL:http://www.python.org/dev/peps/pep-3143/>.

The OP's code does most of what the Linux/BSD daemon() call does, except
that it doesn't close or replace inherited descriptors.

Many of the recommendations in PEP 3143 are "optional extras".

The main "requirement" which cannot reasonably be encapsulated into a
daemon() procedure is to avoid subsequently acquiring a controlling
terminal (by passing O_NOCTTY to all open() calls). Even if Python was to
integrate this into open() (and similar), there's no guarantee that
libraries used via extension modules or ctypes will do likewise.

 | 
Pages: 1
Prev: announcing jsonutil package
Next: how to convert a sudsobject into its representative XML?