Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Ubuntu kernel bug causes container crashes

lwn.net

Post reply on HN
Print view View original

91–100 of 133 posts

Re: An Ubuntu kernel bug causes container crashes

#91

Post by [deleted] »

capableweb wrote: post #59
speedgoose wrote: post #23

Earlier quoted context omitted.

I think it’s more complex to ask people to package software in a good way without software containers.

Is it really? Windows have .exe files, macOS has .app files, Linux has .AppImage (or even tarballs with binaries), and that's just on the host level. Java has .jar files, and so on. Not to mention, if you want to "natively" pack something for Windows and macOS, containers won't even solve that problem, as they only run on Linux. Only reason you can use Docker on macOS is because of virtualization.

[deleted]

Re: An Ubuntu kernel bug causes container crashes

#92

Post by cpach »

heurisko wrote: post #76

I like Ubuntu, but in the last few months I have been following how things are packaged more closely. For example, looking at the package for postgresql-14, an update still hasn't been released for the unscheduled mid-June release version 14.4, which fixed possible index corruption. http://changelogs.ubuntu.com/changelogs/pool/main/p/postgres... I would have thought this would have been packaged earlier, as I would e…

“It makes me wonder exactly how much of a resource is behind creating Ubuntu distributions.”

I don’t really have any sources to back this up, but my impression is that Canonical is kinda trying to punch above their weight.

Re: An Ubuntu kernel bug causes container crashes

#93

Post by tpetry »

atoav wrote: post #16

The cost of complexity showing itself. A sysadmin friend of mine is totally against docker and his reason is that he wants as little complexity as is needed on his systems. Complexity, he says, leads to emergent behavior.

Interestingly solutions like docker csn also make the system less complex. With CoreOS you get an operating system reduced to the bare bones just for running containers, there‘s a lot less complexity if your os is only designed to run containers and nothing else.

Re: An Ubuntu kernel bug causes container crashes

#94

Post by dncornholio »

jillesvangurp wrote: post #15
MBCook wrote: post #10

This seems like the kind of thing that automated testing should have been able to catch. It’s not like running Docker is a small use-case these days.

My thoughts exactly, the details of what this bug is about technically are interesting and fascinating but the key take away is that something went terribly wrong with Ubuntu's testing processes. This should not have shipped without more scrutiny. Somebody presumably cut some corners there and it's worrying that that is possible at all. I actually rolled out Ubuntu 22.04 to a few servers a few weeks ago. Pretty uneve…

> I don't see the value of opting out of 2-3 years worth of known & fixed stability, performance, and other issues.

My 3 year old server is running fine. What am I missing out on exactly? My 6 year old router is also running perfectly. Don't fix what isn't broken. Updates often break things without providing me any value.

I'm running a 5 year old Android. Upgrading to a newer version will slug my phone. I don't need a newer android (yet). My phone works perfectly for me.

Now, if you are going to tell me my security is at risk. Please be specific and provide an example :)

Re: An Ubuntu kernel bug causes container crashes

#95

Post by speedgoose »

capableweb wrote: post #59
speedgoose wrote: post #23

Earlier quoted context omitted.

I think it’s more complex to ask people to package software in a good way without software containers.

Is it really? Windows have .exe files, macOS has .app files, Linux has .AppImage (or even tarballs with binaries), and that's just on the host level. Java has .jar files, and so on. Not to mention, if you want to "natively" pack something for Windows and macOS, containers won't even solve that problem, as they only run on Linux. Only reason you can use Docker on macOS is because of virtualization.

A software container is a bit more than a binary or a software package. It also includes the dependencies and the required files. It’s not only a .jar but a .jar with a compatible JVM with the compatible dependencies.

I don’t think that it uses virtualisation on windows or Mac is very bad. I think that it’s an advantage for simplicity that everything is Linux (I pretend that windows containers do not exist).

Re: An Ubuntu kernel bug causes container crashes

#96

Post by jcastro »

stingraycharles wrote: post #71
QuentinM wrote: post #12

Earlier quoted context omitted.

Sounds about right. And not the first time it happens either. I recall getting a few of those instant unit 3 panic over the past few years with Ubuntu. Often with things not as common out there in production, like tc (which in our case we were using in production to work around conntrack race conditions), and sometimes we also got non-panicking but absolutely production/nerve wrecking issues like TCP window size calc…

It really seems like there’s no good non-redhat (but still “production capable”) alternative to CoreOS nowadays, right? It’s pretty much Fedora / Redhat CoreOS or go directly to things such as k3os?

Try flatcar: https://www.flatcar.org/

Re: An Ubuntu kernel bug causes container crashes

#97

Post by hansel_der »

withinboredom wrote: post #42
_y5hn wrote: post #21

Earlier quoted context omitted.

Wouldn't rollback of kernel be a choice in grub menu? It's pretty standard for all distros to have that choice.

That usually requires physical access to the server to select it during boot.

no.

it requires acces to the serial console or baseband management controller or whatever terms have emerged.

have never rented a physical server w/o this.

Re: An Ubuntu kernel bug causes container crashes

#98

Post by darkwater »

withinboredom wrote: post #42
_y5hn wrote: post #21

Earlier quoted context omitted.

Wouldn't rollback of kernel be a choice in grub menu? It's pretty standard for all distros to have that choice.

That usually requires physical access to the server to select it during boot.

If you have unattended-upgrade and automatic reboot in the cloud to benefit from security updates for long-lived instances, then you better make sure to have a tty console attached to it. You are treating it like a physical machine, you must have the same tooling around.

Re: An Ubuntu kernel bug causes container crashes

#99

Post by markstos »

capableweb wrote: post #58
akx wrote: post #25

Earlier quoted context omitted.

> have to follow the procedure for restoring from backup or re-mounting the root volume on an alternate house to revert the kernel version being run. Or add `systemd.mask=docker.service` to your boot parameters to prevent Docker from starting.

Which, if your server is stuck in a infinitive "boot -> docker starting -> container starting -> crashing kernel -> reboot" loop, you won't ever get a chance of actually adding anything to your boot parameters.

AWS at least provides serial console access so have the option to access it during the boot cycle.

Alternatively, you umount the drive, attach it to another machine, chroot into it, fix grub or whatever, reverse the process and boot again. It's a few steps, but can be done in a few minutes with practice.

Re: An Ubuntu kernel bug causes container crashes

#100

Post by markstos »

gtirloni wrote: post #82
sofixa wrote: post #39

Earlier quoted context omitted.

> If you had `unattended-upgrades` running and had the "automatic reboot" option enabled, then all your Ubuntu 20.04 servers running Docker would reboot themselves and not come back up. Isn't the common wisdom that you should have them enabled, but staggered across hours/days?

Not a huge Debian/Ubuntu user but I think the systemd timer that triggers the unattended updates has a random delay added to it. I don't know of it's hours or just seconds.

I believe it's staggered across hours by default and it seems that Canonical might have been able to at least stop pushing out the bad update even before they had a fix
Post reply on HN