Possibly related to 729889 (*dbm backends don't lock on
commit)

Roundup has not once ever removed a db/lock file, and
this interferes with my incoming email processing. As
far as I can tell, the lock file probably should go
away if no process is actively altering the database. 

Specifically, a sendmail alias triggers roundup-mailgw
to run when a new message arrives, and this fails
because there's already a lock file with the PID of
roundup-server in it. I am able to successfully receive
a new message if I do the following: remove the
lockfile, start roundup-server, send an email, and
remove db/lock again. But if I don't remove db/lock
myself, email will bounce or the web interface will error.

I am interested in workarounds as well as proper
solutions, as I wish to demo roundup (with email) asap.

Logged In: YES 
user_id=6405

The presence of the lock file won't stop access - only a
process actively locking it. Are you sure there are no
accesses active on the roundup-server when the email
delivery is attempted?

Logged In: YES 
user_id=127598

Thank you for your quick response Richard!

> Are you sure there are no
>accesses active on the roundup-server when the email
>delivery is attempted?

To my best understanding, no. I think I can narrow down the
issue: I
start the tracker like so- "roundup-server -l tracker.log -d
tracker.pid -p 8001 it=/home/drewp/trackers/it" and observe
no db/lock
file. Then I go to the web page with the tracker
(http....roundup/it/). I have no relevant cookies, so I see
the issue
list as 'anonymous'. Now, several seconds after loading that
page, I
see db/lock which contains the proper PID of roundup-server. An
incoming email will fail, as I described yesterday.

So, is that lock file behavior correct? An incoming email
bounces with
this error:
  File
"/usr/local/lib/python2.1/site-packages/roundup/backends/locking.py",
line 36, in acquire_lock
    file = open(path, 'w')
IOError: [Errno 13] Permission denied:
'/home/drewp/trackers/it/db/lock'

Logged In: YES 
user_id=6405

Looks to me that the user the mail delivery is running as doesn't have write 
permission on the lock file.

Logged In: YES 
user_id=127598

Indeed. It was a permissions problem. I had trouble
controlling (and knowing) what user sendmail ran as, and
getting the group settings right. 

For the record, it seems that the lock file stays in place
even though the PID listed inside may no longer be running,
and the lockfile gets rewritten by the new process. I had
been trying to make it possible for the new process to
create a new file in the directory, which was the wrong goal.

Finally- isn't this lockfile policy a little screwy? PIDs
get recycled, so it would seem that if a stray process
coincidentally got the PID in the lockfile, roundup might
stall. Hopefully there's a flaw in this theory.

Thanks for all your help Richard!

Logged In: YES 
user_id=6405

Just for the record - the contents of the lockfile are completely 
arbitrary. Having the PID in there is useful for debugging.