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

Jump to bottom

Delete /tmp/whateverable/rakudo-moar/* builds older than max possible timeout #144

Open
MasterDuke17 opened this issue May 19, 2017 · 6 comments
Open

Delete /tmp/whateverable/rakudo-moar/* builds older than max possible timeout #144

MasterDuke17 opened this issue May 19, 2017 · 6 comments
Labels
whateverable Issues affecting the bot framework (and therefore all of the bots)

Comments

@MasterDuke17
Copy link
Collaborator

See https://irclog.perlgeek.de/perl6-dev/2017-05-19#i_14607655 for example of the problem. We could probably just delete any builds where the creation date of the folder is older than the max TOTAL-TIME allowed for any of the bots to run. Do it here (https://github.com/perl6/whateverable/blob/master/Whateverable.pm6#L168-L176) maybe?
@AlexDaniel
Copy link
Member

Yes, the line numbers are correct. That's exactly where I would expect it to happen.

@AlexDaniel AlexDaniel added the whateverable Issues affecting the bot framework (and therefore all of the bots) label May 19, 2017
@zoffixznet
Copy link
Contributor

zoffixznet commented May 19, 2017 •
edited

(permalink to the last link in OP in case code in master changes: https://github.com/perl6/whateverable/blob/09c46d5915edfca48944fc8854dc85697cdf0d3d/Whateverable.pm6#L168-L176 )

@MasterDuke17
Copy link
Collaborator Author

We'll need to use the --touch tar option when extracting builds, otherwise the file creation date will be when the build was originally created, which will almost always be much older than the max possible timeout.

@AlexDaniel AlexDaniel added the good first issue Low-hanging fruit (relatively easy issue, good for drive-by contributions) label May 20, 2017
AlexDaniel added a commit that referenced this issue Sep 29, 2017
@AlexDaniel
I ♥ systemd
845db2e 
This commit resolves many long-standing problems:

* Issue #25 (RESTRICTED setting) is resolved. Bots are still not fully
  secure, but now they are more secure that they've even been given
  that RESTRICTED setting is entirely useless
* Issue #52 (predictable filenames) is no longer blocked
* Issue #55 (sandboxable) is probably no longer relevant
* Issue #118 (ramfs for /tmp) now needs an update
* Issue #144 (bots leaving stuff behind) is resolved because every bot
  has its own /tmp
* Issue #183 (source ip issue) possibly has a systemd solution for it
* Issue #197 is tackled a little bit also because now there's a memory
  limit for every bot (3G for now, we can probably make it smaller)
* Issue #238 (e.g. forkbombs) is basically resolved, but needs a bit more work
* Moreover, there's now a watchdog that makes sure that bots come back
  online if something bad happens

Not that all of this wasn't possible without systemd, it's just that
it is so much easier now. Feel free to hate me as much as you want.
@AlexDaniel AlexDaniel removed the good first issue Low-hanging fruit (relatively easy issue, good for drive-by contributions) label Oct 1, 2017
@AlexDaniel
Copy link
Member

Ah. This is no longer a problem after 845db2e. Every bot has its own private /tmp which is wiped when the service is restarted.

@AlexDaniel AlexDaniel added the testneeded Issue is generally resolved but tests were not written yet label Oct 1, 2017
@AlexDaniel
Copy link
Member

OK it may be a problem for the bot itself if it left something behind and never exited, but so far this has never happened. Non-issue really, but not sure how to test it.

@AlexDaniel AlexDaniel removed the testneeded Issue is generally resolved but tests were not written yet label Jun 2, 2018
@AlexDaniel
Copy link
Member

I'd call this unfixed. During the squashathon some people reported stuff being left behind, so it is still a problem (even if it doesn't affect the bots on the server). See also #122.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
whateverable Issues affecting the bot framework (and therefore all of the bots)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@AlexDaniel @zoffixznet @MasterDuke17