Comment 18 for bug 424462

I can also confirm this bug still exists in 0.4.7 on lucid, although it is partially fixed when handling signals (albeit not really, more on that later).

First, the lock file still remains after an ungraceful exit. For example - adding an invalid repository to mirror.list will cause apt-mirror to fail and exit without deleting the lock. The lock will then need to be manually deleted before apt-mirror can run again. This is a problem when mirroring an unreliable repository since it will break automatic mirroring if the source repo is down when apt-mirror is run. (This should perhaps also be a separate bug since, IMHO, a single broken repo shouldn't cause the entire mirror process to fail. Or is this a feature?)

Try this:
1) Add bogus repo to you mirror config (ie 'deb http://bogusrepository.com/ubuntu lucid main')
2) Run apt-mirror
3) Wait for apt-mirror to fail and exit
4) Run apt-mirror again
5) Note aforementioned error

Second, I can no longer kill apt-mirror with a sigint, sighup, or sigterm - these signals are now seemingly ignored. Upon further inspection, It looks like it is catching the signals, deleting the lock, but fails to actually exit. If a sigint is given during a download stage, it will stop downloading and continue on to the next stage like nothing happened. If sigint is given during the 'proceed indexes' stage, nothing seems to happen other than the lock being deleted.

Try this:
1) Run apt-mirror (with valid config)
2) Press ctrl+c immediately
3) Note index download completes in record time, and apt-mirror proceeds to process indexes
4) While apt-mirror continues, in another terminal, run 'ls /var/spool/apt-mirror/var/apt-mirror.lock'
5) Note no such file error as apt-mirror continues to run in other terminal
6) While apt-mirror continues to process indexes, press ctrl-c again
7) Note apt-mirror continues to process indexes

So yes, the bug still exists in 0.4.7 but with an additional regression.