I had set up version 0.4.3 of RoundUp Tracker to run
the mail gateway when ever an email was recieved
(triggered a script). However, when I installed version
0.5.3 (fresh, clean install) this method would no
longer work. For some reason I could not get permission
to write to the database under that scenario.

Therefore, under 0.5.3, I set up the mail gateway with
cron job to POP the mailbox every 2 minutes.

I had it running like that for a couple of weeks
without incident.

Yesterday we had a network outage at the host where I
host my websites. I did get a lot of cron error
messages later in the day when the site came back up.

But I thought nothing further of it after seeing the
error messages in my email.

Today the system administrator notified me that I had
"lingering processes". 

There were six POP processes from two different
trackers that had not been killed after 24 hours.

The sysadmin feels that as a production script, the
mail gateway (and other parts of the script) should use
alarm() for processes that hang, or should clean up
after itself somehow if it crashes, etc...

Logged In: YES 
user_id=6405

Is the permission problem a local system thing or are you saying that 
something changed in 0.5 that made it not work for you any more? 
 
I'll look into the POP issue. What OS are you running on? 
 

Logged In: YES 
user_id=467955

> Is the permission problem a local system thing or are you
saying 
> that something changed in 0.5 that made it not work for
you any 
> more? 

Error on my part. I didn't have one of the directory
permissions set correctly (I could swear I had checked it
before but...have the mail gateway working correctly now
with script triggering when an email is received).

> I'll look into the POP issue. What OS are you running on?  

Linux.

Logged In: YES 
user_id=6405

I can't reproduce the hang. 
 
I'm going to assume that in some transient state the mailgw was 
able to contact your provider, but that the connection hung 
and wasn't terminated. By default, Python sockets don't time 
out. I'll look into using the timeoutsocket module that's floating 
around on the web. 
 

Logged In: YES 
user_id=6405

Or, since we're not threading, we could just use an alarm like 
your sysadmin suggests. 
 

Logged In: YES 
user_id=6405

The same has happened with the web server. Gah. 
 

Logged In: YES 
user_id=6405

This is the kind of code we need, Windows permitting:

import time, signal

def alarmed(*args):
   raise ValueError, 'alarmed!'

signal.signal(signal.SIGALRM, alarmed)

signal.alarm(5)

try:
    while 1:
      time.sleep(1)
      print 'boo'
      pass
except ValueError, message:
   print 'exiting', message

Logged In: NO 

Windows does not support the SIGALRM flag.

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import signal
>>> dir(signal)
['NSIG', 'SIGABRT', 'SIGBREAK', 'SIGFPE', 'SIGILL',
'SIGINT', 'SIGSEGV', 'SIGTERM', 'SIG_DFL', 'SIG_IGN',
'__doc__', '__name__', 'default_int_handler', 'getsignal',
'signal']
>>> 

I believe you will need windows specific code to accomplish
this on Windows, possibly requiring Mark Hammond's win32
modules.

I personally am only running RoundUP on Linux at this time,
but I know you are striving for cross platform compatibility.

Logged In: YES 
user_id=6405

I guess it'll have to do for now :( 
 
I'll leave the bug open even once the *nix fix is in, on the 
off-chance that some windows expert can enlighten us... 
 

Logged In: YES 
user_id=6405

OK, I've added a default socket timeout to the Roundup scripts, so 
all socket (eg. POP and SMTP) transactions will timeout after a 
minute as long as you're using python 2.3.