Opened 7 years ago

Closed 7 years ago

#5583 closed Bug (fixed)

"blockfile.tmp" file descriptor is leaked when importing blocklist

Reported by: jahutchi Owned by: jordan
Priority: Normal Milestone: 2.83
Component: libtransmission Version: 2.82
Severity: Normal Keywords:


I have posted this on the Forum and they suggested that I raise this as a bug.

I am running transmission v2.82 on Ubuntu 12.10.

I have a cron job which runs every hour to update the blocklist by effectively running "transmission-remote --blocklist-update ..."

The cron job works fine and the blocklist updates correctly. However, after the machine has been left running for several days I was finding that all the disk space on my root partition was being used up (I usually have around 4GB of free space on this partition).

At first it wasn't obvious exactly where the disk space was being used up, since the du command wasn't accounting for anything like the amount of disk reportedly in use when running the df command. However, I did find that if I restarted transmission-daemon then the 4GB of disk space unaccounted for would be freed up - so at this point I knew it had something to do with transmission.

I therefore left my machine running for a few days and found yet again that much of the disk space being used was unaccounted for. After a little further digging I tried running "lsof | grep deleted" which immediately revealed the issue. There were a large number of deleted blocklist.tmp files still sitting in /var/lib/transmission-daemon/info. So it looks like each time I update the blocklist it creates a blocklist.tmp file, which it deletes but fails to release the lock and thus the disk space is not released back to the O/S until transmission-daemon is restarted.

I can also see that this happens when updating the blocklist via the web or by running the "transmission-remote --blocklist-update..." command standalone (i.e. not via my cron script).

It is very easy for me to replicate this - I simply restart transmission-daemon and then run: lsof | grep deleted

This does not show anything other than a couple of deleted system logs from /var/log

I then use the standard web interface to update the blocklist, and confirm this was successful by looking in /var/lib/transmission-daemon/info/blocklists/ to see that the file has been modified.

I then run the command: lsof | grep deleted

Which reveals the following file has been deleted, but the space has not been freed back to the O/S: /var/lib/transmission-daemon/info/blocklist.tmp

If I then update the blocklist again and run "lsof | grep deleted" then I see another entry - infact I am left with one blocklist.tmp file for each and every individual blocklist update whether it's done via the web interface or by using the transmission-remote command. I can also see that the sizes of all these blocklist.tmp files added together do indeed account for the space that is being chewed up on my system.

I have double checked that the O/S user has rwx access to the file - and have even altered the whole of /var/lib/transmission-daemon/ (incl. sub folders and files to have 777 permissions).

As a workaround, I have added a simple nightly crontab entry as root to run "restart transmission-daemon"... However, I thought it would be worth feeding this back incase this is a bug that nobody else has reported yet. Note: I did search the forums before posting this and haven't found any other reports of this same issue.

If there is anything more I can do to help debug the issue then do let me know.

Attachments (1)

rpcimpl.c.diff (546 bytes) - added by rb07 7 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 7 years ago by rb07

To developers:

Seems to me the problem is caused by the file being removed, but not closed. As per man remove(3):

"If the name was the last link to a file, but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed."

Patching rpcimpl.c should solve the issue. I had this already changed on Windows since a problem with shared access to this file was reported (i.e. updating the block list more than once).

Changed 7 years ago by rb07

comment:2 Changed 7 years ago by jahutchi

I have been testing the patch proposed by rb07, and can confirm that this resolves the issue for me.

comment:3 Changed 7 years ago by jordan

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 2.83
  • Owner set to jordan
  • Status changed from new to assigned

Yes, that's definitely a bug, regardless of the symptoms. Any file that gets opened should also get closed. :/

rb07, thanks for the patch.

comment:4 Changed 7 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed
  • Summary changed from Updating the blocklist leaves blocklist.tmp files behind to "blockfile.tmp" file descriptor is leaked when importing blocklist

Patch added to trunk in r14230

Note: See TracTickets for help on using tickets.