Prev: The ol' [[]] * 500 bug...
Next: ANN: PyGUI 2.1
From: Ben Finney on 14 Nov 2009 03:28
Paul Rudin <paul.nospam(a)rudin.co.uk> writes:

> I'm experimenting with the daemon module
> <http://pypi.python.org/pypi/python-daemon/> and upstart
> <http://upstart.ubuntu.com/>.

First: Thank you for using 'python-daemon'; it's getting more widespread
use all the time, which is really helping to find all the quirks of API
and implementation. (And good for my ego at the same time.)

> There's something I don't understand, which may be more of an upstart
> issue than a python issue, but I thought I'd start by posting here.

I'm unfamiliar with 'upstart', I hope others with more experience can
offer more insight.

> Here's a test script:
[…]

The program looks fine to me. What happens if you run the program,
without getting 'upstart' involved?

> and here's a testdaemon.conf upstart configuration:
>
> description "test daemon"
> expect daemon
> chdir /tmp
> exec /tmp/testdaemon.py
>
> If I do "sudo start testdaemon" I see the "testdaemon.py" process
> starting, and the file '/tmp/test.txt' is being written to every 5
> seconds, so everything has kicked off.

Good to know.

> The thing I don't understand is why start does not return. I guess it
> doesn't think that the process and properly started and daemonized
> itself? Quite possibly it's just that I don't understand this stuff
> well...

As I say, I'm completely unfamiliar with the details of 'upstart'. Can
you point me to whatever you used to understand it?

--
\ “I bought some batteries, but they weren't included; so I had |
`\ to buy them again.” —Steven Wright |
_o__) |
Ben Finney
From: Paul Rudin on 14 Nov 2009 11:29
Ben Finney <ben+python(a)benfinney.id.au> writes:

> Paul Rudin <paul.nospam(a)rudin.co.uk> writes:
>
>> I'm experimenting with the daemon module
>> <http://pypi.python.org/pypi/python-daemon/> and upstart
>> <http://upstart.ubuntu.com/>.
>
> First: Thank you for using 'python-daemon'; it's getting more widespread
> use all the time, which is really helping to find all the quirks of API
> and implementation. (And good for my ego at the same time.)
>
>
Thanks for writing it.

> There's something I don't understand, which may be more of an upstart
>> issue than a python issue, but I thought I'd start by posting here.
>
> I'm unfamiliar with 'upstart', I hope others with more experience can
> offer more insight.
>

On Karmic it seems to be the standard way for starting and stopping
system processes.

>> Here's a test script:
> […]
>
> The program looks fine to me. What happens if you run the program,
> without getting 'upstart' involved?
>

As for as I can tell everything is ok invoking the script from the
command line.

>> and here's a testdaemon.conf upstart configuration:
>>
>> description "test daemon"
>> expect daemon
>> chdir /tmp
>> exec /tmp/testdaemon.py
>>
>> If I do "sudo start testdaemon" I see the "testdaemon.py" process
>> starting, and the file '/tmp/test.txt' is being written to every 5
>> seconds, so everything has kicked off.
>
> Good to know.
>
>> The thing I don't understand is why start does not return. I guess it
>> doesn't think that the process and properly started and daemonized
>> itself? Quite possibly it's just that I don't understand this stuff
>> well...
>
> As I say, I'm completely unfamiliar with the details of 'upstart'. Can
> you point me to whatever you used to understand it?

The man pages on Karmic - "man start" etc. and the documentation on the
upstart website: <http://upstart.ubuntu.com/> - check the getting
started page and the wiki. Also some blog pages by its author:
<http://www.netsplit.com/category/tech/upstart/>
From: Paul Rudin on 14 Nov 2009 11:56
Paul Rudin <paul.nospam(a)rudin.co.uk> writes:

> Ben Finney <ben+python(a)benfinney.id.au> writes:
>
>> Paul Rudin <paul.nospam(a)rudin.co.uk> writes:

>>> description "test daemon"
>>> expect daemon
>>> chdir /tmp
>>> exec /tmp/testdaemon.py

Further experimentation reveals that by omitting the "expect daemon"
stanza everything works fine. But I'm still a confused - the manpage
says:


expect daemon
Specifies that the job's main process is a daemon, and will fork
twice after being run. init(8) will follow this daemonisation,
and will wait for this to occur before running the job's post-
start script or considering the job to be running.

Without this stanza init(8) is unable to supervise daemon pro‐
cesses and will believe them to have stopped as soon as they
daemonise on startup.


So I would have expected it to be necessary in this case. Maybe this is
more an upstart issue than a python-daemon one - not sure.

From: Paul Rudin on 14 Nov 2009 14:41
Paul Rudin <paul.nospam(a)rudin.co.uk> writes:

>
> So I would have expected it to be necessary in this case. Maybe this is
> more an upstart issue than a python-daemon one - not sure.

Aha - so I discover that if detach_process is not explicitly passed to
the DaemonContext initialiser it tries to guess whether it needs to do
the double fork thing or not, passing it through explicitly makes every
work as I expected.

So it's probably an rtfm error on my part. Although I suppose that there
may be an argument the the DaemonContext guessing should try and detect
this situation.... not sure.
 | 
Pages: 1
Prev: The ol' [[]] * 500 bug...
Next: ANN: PyGUI 2.1