Closed opello closed 1 year ago
It might be most appropriate to just push this as a special synology tagged build with some explanation about it being for their special kernel if you have the "steamcmd takes 99% CPU" issue?
Hey @opello, thank you for the PR!
This is pretty funky indeed, but if it means that we can ditch the debian10 branch and provide crossplay for all I'm all for it.
it is difficult to control what programs may call what other programs
I'm not really concerned with any programs outside of valheim-server and the misc. helpers this container uses. So as long as it's compatible with those I think this is good to merge to main.
You're quite welcome, thanks for the container in the first place!
All of the other pieces that I saw were 64-bit binaries anyway, so this shouldn't even affect them. The big 32-bit binary that was a problem was steamcmd and this does avoid the large issue there on Synology hardware and doesn't introduce any issues that I saw on vanilla kernels.
Some Synology users face a problem with glibc >= 2.31 due to collisions in the syscall number assignments. Synology uses some that have since been used for other things in mainline Linux. The one that exposed the issue here is clock_gettime64 being #403 in mainline Linux while in the Synology kernel exhibiting the issue it is SYNOArchiveBit. Suffice it to say these functions are not interchangeable. It seems that glibc can not tell the difference and working around the issue is required.
This seemed as clean as providing a wrapper library using LD_PRELOAD that ensured none of the 32-bit programs this image cared about would step on the wrong syscalls, because it is difficult to control what programs may call what other programs. This is admittedly a little dirty, since the x86_64 execution will be using glibc 2.31 and the i386 environment will be using 2.28.
In practice I did not see any adverse effects, but it is not heavily exercised. Just in launching valheim-server with -crossplay and ensuring libpary.so loaded successfully.