Re: [Twisted-Python] twistd --uid and --logfile
On 06:14 pm, d...@krondo.com wrote: >On Tue, Aug 17, 2010 at 10:40 AM, wrote: >>On 11:35 am, zoran.bosn...@sloveniacontrol.si wrote: >>>I am running twisted application from /etc/init/myapp.conf by exec >>>statement like this: >>>exec /usr/bin/twistd --uid= --gid= >>>--logfile=/var/log/dir/file >>> >>>The problem is when log file is first created under /var/log/dir (dir >>>is >>>owned by user id), the owner of the file is 'root', not requested >>>user. >>>As a consequence, the twistd is not able to rotate log files. >>> >>>If the logfile is already created (and chowned) before running >>>twistd, >>>there is no problem. It looks like set uid/gid is called too late >>>inside >>>twistd. It is suppose to be called before creating a logfile. >>> >>>Is this a bug or am I missing something? >> >>If or has write permission on /var/log/dir/ then rotation >>should work, even if or does not own the first logfile >>created. > >That's true. It does seem reasonable, however, that the log files would >get created with the uid/gid that you specified. I've been surprised by >this >in the past as well. Any reason not to do that? No. It works the way it does now by accident. The code in question is quite complicated and not necessarily fully covered by the test suite. And the actual behavior of the --uid/--gid options isn't documented anyway, so it's not clear what you *should* expect from it, nor which of its current behaviors people /do/ expect from it. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Multiple Sources for Logging
Yes Server.site does indeed take a logPath arg. Now how can I amend my code so that I can see both sys.stdout and my log file both being written at the same time? ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] twistd --uid and --logfile
On Tue, Aug 17, 2010 at 10:40 AM, wrote: > On 11:35 am, zoran.bosn...@sloveniacontrol.si wrote: >>I am running twisted application from /etc/init/myapp.conf by exec >>statement like this: >>exec /usr/bin/twistd --uid= --gid= --logfile=/var/log/dir/file >> >>The problem is when log file is first created under /var/log/dir (dir >>is >>owned by user id), the owner of the file is 'root', not requested user. >>As a consequence, the twistd is not able to rotate log files. >> >>If the logfile is already created (and chowned) before running twistd, >>there is no problem. It looks like set uid/gid is called too late >>inside >>twistd. It is suppose to be called before creating a logfile. >> >>Is this a bug or am I missing something? > > If or has write permission on /var/log/dir/ then rotation > should work, even if or does not own the first logfile > created. That's true. It does seem reasonable, however, that the log files would get created with the uid/gid that you specified. I've been surprised by this in the past as well. Any reason not to do that? dave ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] twistd --uid and --logfile
On 11:35 am, zoran.bosn...@sloveniacontrol.si wrote: >I am running twisted application from /etc/init/myapp.conf by exec >statement like this: >exec /usr/bin/twistd --uid= --gid= --logfile=/var/log/dir/file > >The problem is when log file is first created under /var/log/dir (dir >is >owned by user id), the owner of the file is 'root', not requested user. >As a consequence, the twistd is not able to rotate log files. > >If the logfile is already created (and chowned) before running twistd, >there is no problem. It looks like set uid/gid is called too late >inside >twistd. It is suppose to be called before creating a logfile. > >Is this a bug or am I missing something? If or has write permission on /var/log/dir/ then rotation should work, even if or does not own the first logfile created. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] twistd --uid and --logfile
I am running twisted application from /etc/init/myapp.conf by exec statement like this: exec /usr/bin/twistd --uid= --gid= --logfile=/var/log/dir/file The problem is when log file is first created under /var/log/dir (dir is owned by user id), the owner of the file is 'root', not requested user. As a consequence, the twistd is not able to rotate log files. If the logfile is already created (and chowned) before running twistd, there is no problem. It looks like set uid/gid is called too late inside twistd. It is suppose to be called before creating a logfile. Is this a bug or am I missing something? Zoran ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] inlineCallbacks cascading cancelling and more
You are currently considering your task from the viewpoint “let's make a
callback chain for the perfect workflow and alter this chain in case of
anything going wrong.” I think the flaw with this approach is that you are
trying to make your “ideal” flow work at all in situations where it would, in
fact, fail for the most of the time.
I am not sure I understand you correct...
In my case when ASR or TTS resource aquiring fails I must transfer call
to operator but not fail.
Instead of this, you could try to reconsider the task from the viewpoint of
“Let's not add any further callbacks until this is absolutely necessary”. For
me, this approach rather works. Moreover, you have the means to do it — a
callback can return a Deferred, and so on.
Good. But I need to start acquiring ASR and TTS resources at one time
(in parallel) because this is very long operations and they can be good
performed in parallel because physically this is other and different
machines (computers). Why we can't do that way? Why user have to wait
double time?
But it doesn't matter, because there is one more thing. Ok. Let's do it
sequentially. But what if user hangs up call? I want to immediately stop
all deferred processes due I don't need their results any more. All
yields inside inlineCallbacks must raise some exception.
This code shows how we can solve this with feautures described
class DestroyingError(Exception):
pass
class DestroySupport(object):
__destroying_deferreds = None
def __get_destroying_deferred(self):
if self.__destroying_deferreds is None:
self.__destroying_deferreds = {}
deferred = defer.Deferred()
self.__destroying_deferreds[deferred] = 1
# delete "destroying" `deferred` when it finished
deferred.addFinalizer(self.__destroying_deferreds.pop, deferred)
return deferred
def wait_destroying(self):
return self.__get_destroying_deferred()
def destroy(self):
if self.__destroying_deferreds is not None:
# errback all "destroying" deferreds
for deferred in self.__destroying_deferreds.keys():
try:
raise DestroyingError('destroying')
except DestroyingError:
deferred.errback()
self.__destroying_deferreds = None
# See InlineCallbacksManager in my first message in current discussion
thread
class
InlineCallbacksWithDestroySupportManager(defer.InlineCallbacksManager):
def __init__(self, instance, *args, **kw):
defer.InlineCallbacksManager.__init__(self, instance, *args, **kw)
# chain Deferred with "destroying" deferred
# therefore if destroy occurs Deferred errbacked with
DestroyingError
destroying_deferred = instance.wait_destroying()
destroying_deferred.chainDeferred(self.deferred)
# unchain if deferred finished (
# "destroying" deferred will be cancelled also due not used
any more
# and deletes from DestroySupport.__destroying_deferreds
due to its finalizer
# we add in DestroySupport.__get_destroying_deferred
# )
self.deferred.addFinalizer(destroying_deferred.unchainDeferredSafe,
self.deferred)
inlineCallbacksWithDestroySupport = defer.create_inline_callbacks_decorator(
InlineCallbacksWithDestroySupportManager
)
class CallService(DestroySupport):
def on_connection_lost(self):
# launch cascade destroying when connection lost!!!
# all yields will raise DestroyingError
# therefore all resources will be released
self.destroy()
@inlineCallbacksWithDestroySupport
def incoming_call(self, call):
call.start_play('music')
try:
# tuple yield feature!
tts, asr = yield self.acquire_tts_for(call),
self.acquire_asr_for(call)
except TimeoutError:
# this occurs if TimeoutError raises in
`self.acquire_tts_for` or `self.acquire_asr_for`
# i.e. DeferredList(..., fireOnOneErrback=1)
call.transfer_to('operator')
# NOTE: at this point I want to automatically _recursively_
(in deep)
# stop all deferred processes
# starting inside `self.acquire_tts_for` and
`self.acquire_asr_for`
# because I don't need their results (and expensive
resources!) any more
except DestroyingError:
log('Destroying detected')
raise
else:
try:
try:
yield tts.speak('what you want? say me after signal')
yield asr.start_recognition()
call.start_play('signal')
result = yield asr.wait_recognition_result()
... do something with result ...
except DestroyingError:
log('Destroying detected')
raise
finally:
Re: [Twisted-Python] Multiple Sources for Logging
On 8/17/10 6:24 AM, disappearedng wrote: > Dear Everyone, > > I am running WSGI inside my twisted server. I am currently using > startLogging, but I am interested in separating the two sources of > logs into different destinations, i.e. different log files. Take a > look at my log: To the best of my knowledge the twisted.web.server.Site constructor takes a logPath argument, that should point to a log-file where access loglines are put. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] inlineCallbacks cascading cancelling and more
On Aug 17, 2010, at 8:49 AM, Sergey Magafurov wrote: > ... lots of text skipped ... You are currently considering your task from the viewpoint “let's make a callback chain for the perfect workflow and alter this chain in case of anything going wrong.” I think the flaw with this approach is that you are trying to make your “ideal” flow work at all in situations where it would, in fact, fail for the most of the time. Instead of this, you could try to reconsider the task from the viewpoint of “Let's not add any further callbacks until this is absolutely necessary”. For me, this approach rather works. Moreover, you have the means to do it — a callback can return a Deferred, and so on. Hope that helps. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
