Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aptly 1.0.0 doesn't remove /tmp files after publish finished #543

Closed
vhbatista opened this issue Apr 10, 2017 · 6 comments
Closed

aptly 1.0.0 doesn't remove /tmp files after publish finished #543

vhbatista opened this issue Apr 10, 2017 · 6 comments
Labels

Comments

@vhbatista
Copy link

When running aptly publish repo, it generates folders on /tmp in the form /tmp/aptlyNNNNNN and they're not removed after finishing process.

Detailed Description

After upgrading aptly from 0.9.6 to 1.0.0 I've found that a lot of folders /tmp/aptlyNNNNN are created and never removed. Since we have a pretty heavy usage of our repositories, the created folders end up filling the disk.

Possible Implementation

Remove /tmp/aptly folders after publish ends.

Your Environment

Ubuntu 14.04.

@smira
Copy link
Contributor

smira commented Apr 10, 2017

@demasiadovivo any additional details? what kind of publishing are you using? local, S3, Swift? are these only folders left behind or some contents as well?

@smira smira added the bug label Apr 10, 2017
@vhbatista
Copy link
Author

Hi @smira, I'm using local publish, and after reading your question I realized that I didn't tell I'm using publish update:
$ aptly publish update xenial production

Leaved /tmp folders have several files on them:
$ ls /tmp/aptly*
/tmp/aptly716207880:
main_binary-amd64_Packages main_binary-i386_Packages

/tmp/aptly722240269:
000219.ldb 000222.ldb 000224.ldb 000226.ldb 000228.ldb 000230.ldb 000232.ldb 000234.ldb CURRENT LOG
000221.ldb 000223.ldb 000225.ldb 000227.log 000229.ldb 000231.ldb 000233.ldb 000235.ldb LOCK MANIFEST-000000

/tmp/aptly978672292:
001989.log 002001.ldb 002007.ldb 002013.ldb 002019.ldb 002025.ldb 002031.ldb 002037.ldb 002043.ldb 002049.ldb MANIFEST-000000
001996.ldb 002002.ldb 002008.ldb 002014.ldb 002020.ldb 002026.ldb 002032.ldb 002038.ldb 002044.ldb 002050.ldb
001997.ldb 002003.ldb 002009.ldb 002015.ldb 002021.ldb 002027.ldb 002033.ldb 002039.ldb 002045.ldb 002051.ldb
001998.ldb 002004.ldb 002010.ldb 002016.ldb 002022.ldb 002028.ldb 002034.ldb 002040.ldb 002046.ldb CURRENT
001999.ldb 002005.ldb 002011.ldb 002017.ldb 002023.ldb 002029.ldb 002035.ldb 002041.ldb 002047.ldb LOCK
002000.ldb 002006.ldb 002012.ldb 002018.ldb 002024.ldb 002030.ldb 002036.ldb 002042.ldb 002048.ldb LOG

I'm counting two or more folders created on each execution. Repositories are big, since they include Ubuntu mirrors.

@smira
Copy link
Contributor

smira commented Apr 10, 2017

thanks, looks like it's leftover from Contents generation, I'm going to take a look into it

@smira
Copy link
Contributor

smira commented Apr 10, 2017

@demasiadovivo aptly_1.0.0+19+gac475c0 nightly was published which includes the fix, would you mind giving it a try?

If testing succeeds, I'm going to build 1.0.1 version with this fix

Thanks for the bug report!

@vhbatista
Copy link
Author

@smira thank you for the quick response and fix!

I've tested on a qa environment with a smaller repo and had these results:

  • If publish finishes, everything works as expected, tmp folders are removed.
  • If I interrupt publish process (for ex with ctrl+c), tmp folders stay there, they're not removed.

I found that the same happens if I interrupt a mirror update, when executing something like "aptly mirror update xenial".

I think the general case is solved, but would be great if a catch for interrupts like SIGTERM is added, so if a mirror update or publish fails for some reason, the tmp folders are removed.

Thank you again.

@smira
Copy link
Contributor

smira commented Apr 11, 2017

Thanks for the testing, I'll get 1.0.1 released today with just this fix on top of 1.0.0

For the general case, I agree that aptly should cleanup after itself on signals, I will put that as separate issue for the next release, as that plays well with Go 1.7+ context module, but that requires dropping support for Go 1.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants