Yggdrasil library not found after upgrade to 5.1.1

[baltie]

Describe the bug
After upgrading from version 5.1.0 to 5.1.1, we get a TypeInitializationException and our service refuses to start.

To Reproduce
Create new .NET 8.0 project with Unleash client 5.1.1 package and initialize the client. Publish it as a Docker image based on mcr.microsoft.com/dotnet/aspnet:8.0-alpine. Run the image and see that it fails during initialization of Unleash.

Log output

System.TypeInitializationException: The type initializer for 'Yggdrasil.FFI' threw an exception.
 ---> System.IO.FileNotFoundException: Embedded resource libyggdrasilffi_x86_64-musl.so not found.
   at NativeLibLoader.LoadNativeLibrary()
   at Yggdrasil.FFI..cctor()
   --- End of inner exception stack trace ---
   at Yggdrasil.FFI.NewEngine()
   at Yggdrasil.YggdrasilEngine..ctor(List`1 strategies)
   at Unleash.UnleashServices..ctor(UnleashSettings settings, EventCallbackConfig eventConfig, List`1 strategies)
   at Unleash.DefaultUnleash..ctor(UnleashSettings settings, IStrategy[] strategies)
   at ***
   at Program.<Main>$(String[] args)

Desktop (please complete the following information):

• OS: Alpine Linux 3.21.3

[daghsentinel]

+1

[Ken-From-The-Deep]

+1, and also on Alpine Linux.

[daveleek]

Thank you @baltie, @daghsentinel , @Ken-From-The-Deep for reporting this! we're looking into it and will get back to you!

[daveleek]

Hello again @baltie, @daghsentinel, @Ken-From-The-Deep! We just released Unleash.Client v 5.2.1 to NuGet where this issue should now have been resolved! Thank you for reporting this and for your patience!

[jstaro]

v5.1.1 also seems to require a r/w filesystem, which 5.1.0 did not. Just tested 5.2.1 and it has the same issue.

System.TypeInitializationException: The type initializer for 'Yggdrasil.FFI' threw an exception.
 ---> System.IO.IOException: Read-only file system : '/tmp/libyggdrasilffi_x86_64.so'
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at NativeLibLoader.LoadNativeLibrary()
   at Yggdrasil.FFI..cctor()
   --- End of inner exception stack trace ---
   at Yggdrasil.YggdrasilEngine..ctor(List`1 strategies)
   at Unleash.UnleashServices..ctor(UnleashSettings settings, EventCallbackConfig eventConfig, List`1 strategies)
   at Unleash.DefaultUnleash..ctor(UnleashSettings settings, IStrategy[] strategies)
   at <REDACTED>.Application.Configuration.ConfigurationExtensions.ConfigureUnleash(WebApplicationBuilder builder, IAppConfig config) in <REDACTED>/Application/Configuration/ConfigExtensions.cs:line 116
   at Program.<<Main>$>g__ConfigureServices|0_0(WebApplicationBuilder builder, IAppConfig config) in <REDACTED>/Program.cs:line 42
   at Program.<Main>$(String[] args) in <REDACTED>/Program.cs:line 18

[daveleek]

Hello @jstaro!

Which .NET and OS versions are you running if you don't mind? Could help in identifying other ways of solving this.:

Due to restrictions in the NuGet package dependency configuration API and our dependency on (a lot of different) native DLLs (yggdrasil) we needed to embed the libraries into one. We then at runtime figure out which native library to load, write that library out to Path.GetTempPath() and load it dynamically.

We do however also check if the library we need already exists before doing this, which opens up a solution for the issue you're experiencing: I was able to get a read-only container running by manually mapping the assembly-file into /tmp/ (in this case) in my docker-compose. The file is mapped into each release of Yggdrasil.Engine from the Yggdrasil project correspondingly referenced release. Another option is if you're running tests/or the application in some form during building the container you could copy the yggdrasil library from the build image into the tmp folder of the release image.

[jstaro]

@daveleek
Running in k8s with the following base image:
docker pull mcr.microsoft.com/dotnet/aspnet:9.0@sha256:28d439d04099c7cb9d6cfc7addd946c17bf029ff98e6d73760e3359aef258072

Operating system: Unix 5.10.233.224 (docker, dotnet-chiseled)
Runtime version: .NET 9.0.0

Thanks for a possible workaround; however that's probably a bit more involved than what we probably want to do and maintain. Might even prefer to mount /tmp as writeable. For now we downgraded.