Ask questionsmonerod crashes during resync: Exception in threadpool
monerod on latest 0.17.1.1, the node repeatedly crashes during resync with the following output:
2020-10-31 15:18:25.197 [P2P3] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:368 [220.127.116.11:18080 OUT] Sync data returned a new top block candidate: 2210000 -> 2220390 [Your node is 10390 blocks (14.4 days) behind] 2020-10-31 15:18:25.197 [P2P3] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:368 SYNCHRONIZATION started 2020-10-31 15:18:30.508 [P2P0] ERROR default src/common/threadpool.cpp:170 Exception in threadpool job: mprotect failed
I am running monerod v0.17.1.1 on Ubuntu 20.04.
Answer questions tevador
According to the systemd man pages, this is not a bug but the intended behavior of the
MemoryDenyWriteExecute= Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited. Specifically, a system call filter is added that rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of various C compilers.
Emphasis mine. The issue is that it not only enforces W^X, but also prevents existing mappings from being made executable. No JIT compiled code can work under these circumstances. If you insist about having it on, you need to use
MONERO_RANDOMX_UMASK=8, which disables JIT altogether (at the cost of a much slower synchronization).