search

m1k1o / neko

A self hosted virtual browser that runs in docker and uses WebRTC.
https://neko.m1k1o.net/
Apache License 2.0
5.98k stars 449 forks source link

X issues/crashes #159

Open lowne opened 2 years ago

lowne commented 2 years ago

Just wanted to have an issue to track possible repercussions of #151 - feel free to close after a while if nobody chimes in.

Copypaste from PR

Sometimes on container startup X will throw a fit with (possibly non-exhaustive list):

Xorg: ../../../../../../include/privates.h:121: dixGetPrivateAddr: Assertion 'key->initialized' failed.
Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion '!global_keys[type].created' failed.

as soon as neko starts (and then neko itself dies). When that happens supervisord will restart both and soon enough they'll both manage to say alive and settle down. Looking for clues reveals a bunch of long-standing X bugs with a bunch of supposed patches and the general advice of "start X as root kthx" (which is not the case in neko, as it stands).

References

Some of the links I dug up:

And a hilarious quote from one of them which perhaps accurately reflects the state of Xorg:

Is there another workaround?

Yes, just select 'Ubuntu on Wayland' from the login screen.

Which had me think that maybe one day in the distant future it might be nice to switch to wayland+pipewire...

m1k1o commented 2 years ago

Looks like this addition made mutliplatform build to fail. https://github.com/m1k1o/neko/runs/5955936398?check_suite_focus=true

Either we shoudl find multiplatform solution for this or at least install it only when it is ams64, so that it at least builds.

lowne commented 2 years ago

If you're talking about #151 then absolutely it should only be for amd64, there's no QSV on non-Intel CPUs (and so - reasonably - no related packages for arm64). I haven't touched the build scripts as I don't know how they work, I just saw a Dockerfile.arm and assumed it was the one used for arm builds - and left it untouched.

m1k1o commented 2 years ago

Currenty Dockerfile.arm is used for armv7 and i am experimenting with armv8 in different build pipeline.

it should only be for amd64 Then we either need own build for armv8, or join armv7 and armv8, or add that dependency conditionaly.

lowne commented 2 years ago

own build for armv8

Seems to me like the way to go, I assume armv7 will go away at some point, no?

add that dependency conditionaly.

It's possible, and it's desirable to have a unified pipeline, but imho it creates more headaches than it's worth; the multiarch story in the general Linux ecosystem doesn't seem quite ready yet (and for containers specifically, multiarch still seems to be the exception rather than the norm)