Skip to content

Self-hosted Logflare in Supabase 1.15.4 -> Illegal instruction (core dumped) #2444

Description

@szjozsef

Hello,

I tried to update the supabase/logflare image in a self-hosted supabase setup, from 1.15.3 to 1.15.4 and the container failed to start.

The container logged just this:

LOGFLARE_NODE_HOST is: 127.0.0.1

08:27:25.177 [info] Starting migration

08:27:25.573 [info] Migrations already up

08:27:25.576 [info] Migration finished
Illegal instruction (core dumped)

1.15.3 is working fine on the same host computer

Activity

  1. Ziinc commented on Jun 19, 2025

    @Ziinc
    Contributor

    Hi @szjozsef thanks for the report, could you share some system details that you are running the stack on?

    OS, hypervisor if any, etc would be helpful in narrowing down the issue

  2. szjozsef commented on Jun 19, 2025

    @szjozsef
    Author

    Debian version: 11.11

    Kernel: 5.10.0-35-amd64 #1 SMP Debian 5.10.237-1 (2025-05-19) x86_64 GNU/Linux
    

    48 GB Ram

    CPU: 2 x Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
    CPU Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtop
                                          ology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flex
                                          priority ept vpid dtherm ida arat flush_l1d
    

    docker-ce: 5:28.2.2-1debian.11bullseye
    containerd.io: 1.7.27-1
    docker-compose-plugin: 2.36.2-1debian.11bullseye

    Let me known if I can provide any further information

  3. szjozsef commented on Jul 1, 2025

    @szjozsef
    Author

    The same issue I have also with the version 1.16.0 & 1.16.1, 1.17.0, 1.17.1, 1.17.2, 1.18.0, 1.18.1

    docker logs  supabase-analytics
    LOGFLARE_NODE_HOST is: 127.0.0.1
    
    09:18:00.696 [info] Starting migration
    
    09:18:01.462 [info] == Running 20250702081228 Logflare.Repo.Migrations.AddBigqueryClusteringFieldstoSourcesTable.change/0 forward
    
    09:18:01.463 [info] alter table sources
    
    09:18:01.483 [info] == Migrated 20250702081228 in 0.0s
    
    09:18:01.541 [info] == Running 20250709072539 Logflare.Repo.Migrations.AddLabelsToEndpointQueriesTable.change/0 forward
    
    09:18:01.541 [info] alter table endpoint_queries
    
    09:18:01.543 [info] == Migrated 20250709072539 in 0.0s
    
    09:18:01.553 [info] == Running 20250710164717 Logflare.Repo.Migrations.AddBackendIdToEndpointQueries.change/0 forward
    
    09:18:01.553 [info] alter table endpoint_queries
    
    09:18:01.611 [info] create index endpoint_queries_backend_id_index
    
    09:18:01.645 [info] == Migrated 20250710164717 in 0.0s
    
    09:18:01.662 [info] Migration finished
    Illegal instruction (core dumped)
    LOGFLARE_NODE_HOST is: 127.0.0.1
    
    09:18:19.304 [info] Starting migration
    
    09:18:19.698 [info] Migrations already up
    
    09:18:19.701 [info] Migration finished
    Illegal instruction (core dumped)
    
  4. DanCharousek commented on Oct 9, 2025

    @DanCharousek

    @szjozsef

    Hi, any luck solving the issue?

  5. DanCharousek commented on Oct 11, 2025

    @DanCharousek

    Solved:

    I was facing this issue while spinning up the supabase stack in my proxmox VM. It turned out to be an issue with my VM CPU setting. Changing it to "Host" mode solved the problem. See https://www.reddit.com/r/Oobabooga/comments/1bn4086/comment/kwnskvv/

  6. szjozsef commented on Oct 11, 2025

    @szjozsef
    Author

    @DanCharousek
    Sorry for late reply.
    I have no luck with any newer version of the image.
    In my opinion one of the dependent libraries you are using inside the image is compiled strictly with newer CPU instruction set.
    As I said this change was made beginning with version: 1.15.4
    For me the latest image is 1.15.3 which is still works with the CPU instruction set which is available for me to run the Supabase stack for the moment, The rest of the Supabase containers are running fine on the same hardware.
    I'm running the Supabase stack on Bare Metal server running Debian OS and with latest available docker container tools.

    A common cause for this as an example with gcc compiler is that it is started with the default -march settings or it is wrongly called with -march=native, or has a -march set to a way to newer architecture, limiting the possibility where that build code can be run. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions