One thing that may help is to explicitly destroy the list settings and list archive objects in the archive() subroutine of dada_bridge pl - ala place:

 undef $ls;
 undef $la;

At the end of the archive() subroutine

destroying these objects should unlock the lock file for you; so the next time you archive a message, a new object has to be created They should be removed automatically, because they're out of scope after the subroutine is done - but, perhaps not?

Adding the undef's at the end of archive() did not change anything: the lock file is not removed, the POP3 messages aren't either

>

The smarter idea would be to cache these objects for later use - I think I'm doing this in the bounce handler but that's more of a tuning thing - both ideas may help in fixing this problem

Although I still do not know what the relation is between $pop and system calls, I am pretty sure now that when the archivesdb lock file problem is solved, the undeleted POP3 messages problem will not show up anymore also

Well, messages on the pop server will not get removed when you call $pop->delete() - the message only gets flagged to be removed when you disconnect If the pop server does not disconnect correctly, these flags will not be honored, because they're lost One way to disconnect incorrectly would be to have the program die() on you

Yes, I know about this mechanism I used to run a script written by my own, like dada_bridge, to read a POP3 box and forward it to Dada I used it with dada_send pl and it is working without any problems for 2 years now, although not on the same server I am doing my experiments now

Both $pop->delete() (for every single message) as $pop->quit are executed inside dada_bridge: that means the script is not die'ing What I notice is that $pop methods are not working anymore after archiving For instance, $po p->list(1) should give me the message size of the first message, but it returns nothing The same for $pop->delete() and $pop->quit(): they return false instead of true

So I am pretty sure the $pop variable itself is going out of scope Although when I turn on debugging inside sub pop3_login() as follows:

my $pop = Net::POP3->new($server, Debug =>1)

the debug info doesn't show anything different compared to the normal situation:

Net::POP3>>> Net::POP3(2 28) Net::POP3>>> Net::Cmd(2 26) Net::POP3>>> Exporter(5 562) Net::POP3>>> IO::Socket::INET(1 25) Net::POP3>>> IO::Socket(1 26) Net::POP3>>> IO::Handle(1 21) Net::POP3=GLOB(0x8a25c34)<<< +OK server10 firstfind nl Cyrus POP3 v2 0 16 server ready

Anyway, I will try to find out why the lock file is not removed

Frans