21–30 of 30 posts
I run large datacenters with thousands of boxes. I have a little app (written in golang) installed on each box that effectively is a task runner. Tasks can be written to do anything, including apt-get installing software. If apt-get fails to run, the task fails (context.WithTimeout) and is run again at a later date. No random hacks needed. Everything is built to be idempotent, self-healing and eventually consistent.
Those darned apt locks have to be the second biggest PITA of my Linux development experience. Who in their right mind thought it was a good idea for an automatic system maintenance process to entirely block the user from doing their using for the first couple minutes after startup? As if that wasn’t enough they have the nerve to log this line: > Be aware that removing the lock file is not a solution and may break you…
I run large datacenters with thousands of boxes. I have a little app (written in golang) installed on each box that effectively is a task runner. Tasks can be written to do anything, including apt-get installing software. If apt-get fails to run, the task fails (context.WithTimeout) and is run again at a later date. No random hacks needed. Everything is built to be idempotent, self-healing and eventually consistent.
I run large datacenters with thousands of boxes. I have a little app (written in golang) installed on each box that effectively is a task runner. Tasks can be written to do anything, including apt-get installing software. If apt-get fails to run, the task fails (context.WithTimeout) and is run again at a later date. No random hacks needed. Everything is built to be idempotent, self-healing and eventually consistent.
Might be a dumb question, but would systemd not be able to do this? Do your boxes not run systemd?
I run large datacenters with thousands of boxes. I have a little app (written in golang) installed on each box that effectively is a task runner. Tasks can be written to do anything, including apt-get installing software. If apt-get fails to run, the task fails (context.WithTimeout) and is run again at a later date. No random hacks needed. Everything is built to be idempotent, self-healing and eventually consistent.
Would you be interested in sharing this tool with the world?
Those darned apt locks have to be the second biggest PITA of my Linux development experience. Who in their right mind thought it was a good idea for an automatic system maintenance process to entirely block the user from doing their using for the first couple minutes after startup? As if that wasn’t enough they have the nerve to log this line: > Be aware that removing the lock file is not a solution and may break you…
You can disable automatic updates and instead run them when you want.
Earlier quoted context omitted.
cfengine3 does that (and much more) form me.
cron does that for me, and it's already installed
cron is fine as part of a task scheduler, but even for very basic use cases you'll hit its limitations and will have to work around them.
Earlier quoted context omitted.
You can disable automatic updates and instead run them when you want.
Funny thing is I click “not now” or whatever it is when they pop up asking if I want updates, yet it still gets locked.
https://media.howtofix.io/full/images/posts/2020/11/13/16052...
Other distros may vary :)
Earlier quoted context omitted.
Funny thing is I click “not now” or whatever it is when they pop up asking if I want updates, yet it still gets locked.
If this is an Ubuntu flavor, you can run the "software and updates" program and set "Updates -> Automatically check for updates" to Never. https://media.howtofix.io/full/images/posts/2020/11/13/16052... Other distros may vary :)
