Stuck in Diagnostic Mode - Javascript Engine Error signal: 7 (SIGBUS)

StartOS Support
1

TL;DR: Stuck in Diagnostic Mode “Javascript Engine Error, Unknown Error (signal: 7 (SIGBUS))”. Log shows the Rust process experiencing timeouts.

Hi!

I’ve been happily running the Raspberry Pi Embassy hardware, keeping my StartOS version fairly up-to-date - StartOS: v0.3.5.1 (latest release on GitHub at time of writing).

Running services:

  • Bitcoin Core
  • C(ore) Lightning
  • Electrs
  • Mempool(.space)
  • File Browser
  • Syncthing
  • Gitea

Have some other services installed but deactivated as far as I recall.

Recently, I experienced issues using my node from Sparrow Wallet on another machine.

That prompted me to check the web GUI. It gave me the “StartOS - Diagnostic Mode” screen.

embassy_diagnostic_mode
embassy_diagnostic_mode455×766 23.6 KB

I’ve tried restarting a bunch of times by holding the physical power button. What I think finally helped was picking “System Rebuild”. I’m able to successfully use the node with my remote Sparrow Wallet. However, the Diagnostic Mode screen still shows in place of the web GUI.

The log shows a repeated variant of:

2025-04-14T11:19:18+02:00 2025-04-14T09:19:18.695082Z ERROR run_main: startos::manager: Failed to run health check for mempool: Timeout Error: deadline has elapsed
2025-04-14T11:19:18+02:00 2025-04-14T09:19:18.696791Z DEBUG run_main: startos::manager: Error { source:
2025-04-14T11:19:18+02:00 0: deadline has elapsed
2025-04-14T11:19:18+02:00 Location:
2025-04-14T11:19:18+02:00 /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/convert/mod.rs:716
2025-04-14T11:19:18+02:00 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2025-04-14T11:19:18+02:00 0: startos::procedure::js_scripts::execute
2025-04-14T11:19:18+02:00 at startos/src/procedure/js_scripts.rs:71
2025-04-14T11:19:18+02:00 1: startos::procedure::execute
2025-04-14T11:19:18+02:00 at startos/src/procedure/mod.rs:60
2025-04-14T11:19:18+02:00 2: startos::status::health_check::check
2025-04-14T11:19:18+02:00 at startos/src/status/health_check.rs:71
2025-04-14T11:19:18+02:00 3: startos::manager::health::check
2025-04-14T11:19:18+02:00 at startos/src/manager/health.rs:11
2025-04-14T11:19:18+02:00 4: startos::manager::run_main
2025-04-14T11:19:18+02:00 at startos/src/manager/mod.rs:652
2025-04-14T11:19:18+02:00 Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
2025-04-14T11:19:18+02:00 Run with RUST_BACKTRACE=full to include source snippets., kind: Timeout, revision: None }
2025-04-14T11:19:18+02:00 2025-04-14T09:19:18.740543Z DEBUG run_main:check: startos::manager::health: Checking health of syncthing
2025-04-14T11:19:18+02:00 2025-04-14T09:19:18.765407Z DEBUG run_main:check: startos::manager::health: Checking health of gitea
2025-04-14T11:19:22+02:00 2025-04-14T09:19:22.748262Z DEBUG run_main:check: startos::manager::health: Checking health of filebrowser
2025-04-14T11:19:29+02:00 2025-04-14T09:19:29.318501Z DEBUG run_main:check: startos::manager::health: Checking health of bitcoind
2025-04-14T11:19:29+02:00 2025-04-14T09:19:29.895346Z DEBUG run_main:check: startos::manager::health: Checking health of c-lightning
2025-04-14T11:19:33+02:00 2025-04-14T09:19:33.700784Z DEBUG run_main:check: startos::manager::health: Checking health of mempool
2025-04-14T11:19:33+02:00 2025-04-14T09:19:33.784243Z DEBUG run_main:check: startos::manager::health: Checking health of electrs
2025-04-14T11:19:38+02:00 2025-04-14T09:19:38.240358Z DEBUG run_main:check: startos::manager::health: Checking health of filebrowser

It seems to be timing out for either Syncthing, Gitea or Mempool.

Recent things I’ve done via the web GUI as far as I remember.

Luckily the SSH key allows me to (very slowly) log in, grab the StartOS version detailed in the beginning.

start9@start:~$ df
Filesystem                                   1K-blocks      Used Available Use% Mounted on
udev                                           3753760         0   3753760   0% /dev
tmpfs                                           805092      1536    803556   1% /run
overlay                                        4025452     64604   3960848   2% /
/dev/mmcblk0p2                                 7299708   5477468   1430036  80% /media/embassy/next
tmpfs                                          4025452       100   4025352   1% /dev/shm
tmpfs                                             5120         0      5120   0% /run/lock
/dev/mmcblk0p1                                  258095     74358    183738  29% /boot
/dev/mapper/EMBASSY_<redacted>_main            8138532   1248356   6455184  17% /embassy-data/main
/dev/mapper/EMBASSY_<redacted>_package-data 1913453332 874918548 941262976  49% /embassy-data/package-data
tmpfs                                           805088         0    805088   0% /run/user/1000

htop:
Couldn’t include screenshot since I’m a new user. :\ But nothing shocking, half the 2GB swap is used. The 4 cores oscillating mostly around 45%.
Top processes in screenshot by CPU (all around 20%):

  • check-rpc.sh
  • bitcoind
  • check-synced.sh
  • node --max-old-space-size=16384 /backend/package/index.js

dmesg:

[449204.553186] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449212.745145] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449221.193151] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449221.193292] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449229.385176] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449237.577138] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449245.769172] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449245.769352] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449250.574990] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[449253.961137] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449262.153135] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449270.345132] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449270.345247] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449278.537136] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449286.729140] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449294.921130] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449294.921212] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449303.113132] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449311.305132] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449319.497129] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449319.497416] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449339.581124] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449347.773157] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449355.965115] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449355.965197] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449364.157143] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449372.349112] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449380.541146] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449380.541321] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449388.733138] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449396.925133] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449405.117108] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449405.117275] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449413.310124] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449421.502098] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449429.694095] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449429.694211] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[449437.886141] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449446.087120] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449454.549091] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[449454.549235] I/O error, dev mmcblk0, sector 7765368 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2

dmesg above seems to indicate that the SD card could be failing (https://forums.raspberrypi.com/viewtopic.php?t=382060).

Is there any way to further diagnose this from the CLI? Or what next steps do you recommend?

2

I agree with your diagnosis. I’m not sure why you’d want to go further. It’s not really expected that a mSD card would last more than a few years… which I’ll assume is how old yours is since you’re running such old hardware. If you want to try to keep the existing mSD, or you want to prepare a new one, you’d follow these guides here: Start9 | StartOS (Raspberry Pi)

Certainly replace the mSD with another if you’d like to continue using the Pi4. But do keep in mind that your device is unable to adequately run the services you have installed, and hasn’t been able to so for some time. In particular, you no longer have the RAM and processing power needed to run Bitcoin, which now has a UTXO set that has expanded beyond the capabilities of a Pi4. Running Electrs and Mempool on top is going to massively exacerbate the lack of resources, while keeping funds in CLN is going to be quite risky going forward. You don’t really want to be running a Pi4 for Bitcoin in 2024/25.

3

Thanks for your reply @StuPleb!

RAM-usage is sitting around 2.9/7.68GB. My intent is to try running the Pi4 for some time yet.
Are there any guides for migrating from mSD to running solely from the SSD?

4

That your RAM usage is 2.9/7.68GB doesn’t change the fact that ~9GB of Bitcoin UTXOs can’t fit in 8GB and that the processor is too slow to thrash this much back and forth over a slow USB interface. The Pi is no longer suitable for Bitcoin.

5

If the UTXOs are too many, wouldn’t it be okay for the older ones to live in Swap-space?
My impression was that Bitcoin Core had issues processing ordinals etc due to mainly the mempool-related parts not having been stress-tested in that way before, but that those issues have been fixed since.

Are there any hard numbers, or detailed investigation into what the minimum requirements are + what limits the Pi has?

6

Hi Lumor!

Unfortunately, swap space is not a viable solution for handling the Bitcoin UTXO set on a Pi4. The UTXO set is now around 9GB, which exceeds the available RAM on an 8GB Pi4. When the system tries to use swap to compensate, performance degrades drastically because swap is much slower than RAM, especially on a Raspberry Pi where swap is typically on an SD card or USB SSD. This leads to constant disk thrashing, extremely slow performance, and a high risk of data corruption or hardware failure—especially given the I/O errors and SD card issues already present in your logs.

While there have been improvements in Bitcoin Core’s handling of mempool and ordinals, the fundamental hardware limitations of the Pi4 remain. The processor and memory bandwidth are simply not sufficient to keep up with the demands of a full node, especially when running additional services like Electrs and Mempool. This is not just a matter of software optimization; it’s a hard resource limit.

As for hard numbers, the Bitcoin UTXO set size and the memory requirements are public and can be tracked, but the minimum requirements for a reliable, performant node have outpaced what a Pi4 can provide as of 2025. Most community reports and developers now recommend at least a modern x86_64 system with 16GB RAM and a fast SSD (2TB recomanded) for running a full-featured Bitcoin node with Electrs and Mempool. The Pi4 is no longer considered suitable for this workload, regardless of swap configuration.

In summary: swap cannot compensate for insufficient RAM for the UTXO set, and the Pi4’s hardware is now below the minimum requirements for running a reliable Bitcoin node with modern workloads.

7

Thanks for answering @h0mer!

The answer to the above StackExchange question indicates that there’s a cache for the UTXO set that gets flushed to disk when it hits the limit. Does that cache not help with this kind of thing, at least in more “peaceful” mempool waters, with fewer unconfirmed transactions like we’ve had for the past months?

Maybe recommending against running on a Pi is valid in more adversarial/high utilization scenarios where there’s over a GB of unconfirmed transactions floating around, many being replaced to pay higher fees, etc?