Le Thu, May 07, 2026 at 09:36:04PM +0200, Landry Breuil a écrit : > Le Wed, May 06, 2026 at 07:39:06PM +0200, Lydia Sobot a écrit : > > Well, I ran into a bit of a snag, and I have exhausted all possibilities > > I could come up with to debug this for now, so I am setting it aside to > > those who know what they're doing, and leaving my notes. > > On my machine (arm64), I could run the initial web setup wizard just > > fine, and go all the way through, but attempting to launch it afterwards > > (only to perform a normal startup, opening the offline database console > > is fine) results in a segfault. It took me positively forever to figure > > out how to force debug symbols, but once I did, even more strangely, the > > entire kernel goes down if I try to compile the binary with debug > > symbols enabled, I think during the final linking stage (or towards the > > end in any case), due to not having enough inodes even though I have > > enough disk space, so beware to those attempting to do this on a > > Raspberry Pi 4B+ I guess. I'd appreciate guidance on how exactly to deal > > with this kind of issue in the future, considering that I usually run > > this machine headless and I had to repeatedly power it off manually and > > plug it into a monitor to bring it back to a working state. > > There, however, appears to be a broader issue with RocksDB and Stalwart > > on *BSD, as noted in the following issues: > > https://github.com/stalwartlabs/stalwart/discussions/2755 > > https://github.com/stalwartlabs/stalwart/issues/253 > > i've reproduced the crash on arm64, eg boostrapping it with mostly the > default options, and then trying to start it in gdb the trace is > useless. > > Thread 2 "tokio-rt-worker" received signal SIGSEGV, Segmentation fault. > [Switching to thread 514473 of process 99072] > 0x0000001c47b90570 in ?? () > (gdb) bt > #0 0x0000001c47b90570 in ?? () > #1 0x0000000000000048 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > but honestly i never tried running stalwart on arm64 before, only on > amd64, and i had no issue with the rocksdb backend at the time (last > year or so). The freebsd issues above seem to relate to jemalloc that we > patch out in the port (since it wouldnt build on openbsd anyway). > wonder what would it take to enable the sqlite backend for easier > testing, but iirc that was more or less unsupported upstream... > > diff updated to 0.16.4 with your changes attached, with stalwart-cli > 1.0.5. i'll try to do some testing on amd64. > > i've pushed an arm64 wip package without debug syms in > https://packages.rhaalovely.net/wip/aarch64/ if that helps. > > (fwiw without debug syms it took 12mn to build on amd64 and 26mn on > arm64.. i wouldnt dare building things on raspberries..)
my previous mail didnt go through to ports@ because some line in the diff triggered some regex in majordomo, but here's a version that actually runs on arm64 & amd64, i've been through the bootstrap thing and managed to run the service and connect to it with the admin account that was created during bootstrap on both architectures. the missing key was USE_NOEXECONLY=yes, because aws-lc is a new dependency and that is known for having issues with ld's default of --execute-only. it's supposedly not needed on arm64 but my testing shows it is required there too. i havent tested much further, but that seem to go in the right direction. after starting with the rc script, it correctly drops priviledges to the _stalwart-smtp user and listens on all the ports (25, 465, 993, 995, 4190, 443 & 8080). oks to import stalwart-cli welcome :) Landry
stalwart-0.16.4.diff.gz
Description: application/gunzip
stalwart-cli-1.0.5.tgz
Description: application/tar-gz
