SIGTERM

[v0l]

2024-05-08 13:38:38.465 ( 279.210s) [Ingester 2      ]INFO| sending error to [605]: bad req: std::get: wrong index for variant

Loguru caught a signal: SIGTERM
Stack trace:
10      0x559d2cc8f5f1 /app/strfry(+0x2e5f1) [0x559d2cc8f5f1]
9       0x7fcb744e1305 __libc_start_main + 133
8       0x7fcb744e124a /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7fcb744e124a]
7       0x559d2cc8f06b /app/strfry(+0x2e06b) [0x559d2cc8f06b]
6       0x559d2ccadb91 /app/strfry(+0x4cb91) [0x559d2ccadb91]
5       0x559d2cf4f0e2 /app/strfry(+0x2ee0e2) [0x559d2cf4f0e2]
4       0x559d2cf4eb4c /app/strfry(+0x2edb4c) [0x559d2cf4eb4c]
3       0x7fcb7486e517 std::thread::join() + 23
2       0x7fcb74544c23 /lib/x86_64-linux-gnu/libc.so.6(+0x8ac23) [0x7fcb74544c23]
1       0x7fcb7453fe96 /lib/x86_64-linux-gnu/libc.so.6(+0x85e96) [0x7fcb7453fe96]
0       0x7fcb744f6050 /lib/x86_64-linux-gnu/libc.so.6(+0x3c050) [0x7fcb744f6050]
2024-05-08 13:38:38.529 ( 279.274s) [main thread     ]FATL| Signal: SIGTERM

[hoytech]

Definitely looks like some kind of a bug. What version of strfry were you running? Is it reproducible?

I know a lot of time has passed, but if you still have that strfry executable around, can you put that stacktrace in a file STACKTRACE and run the following command?

addr2line -Cf -e ./strfry `cat STACKTRACE | perl -ne 'm{/strfry\(\+(\w+)\)} && print "$1 "'`

[v0l]

Yes it still seems to be an issue:

Running: https://github.com/v0l/strfry/tree/nextneg

_start
??:?
main
/build/strfry/build/main.cpp:215
run(int, char**)
/build/strfry/build/main.cpp:182
cmd_relay(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)
/build/strfry/src/apps/relay/cmd_relay.cpp:27
ThreadPool<MsgWebsocket>::join()
/build/strfry/src/ThreadPool.h:57

[hoytech]

I'm not really sure what's happening here. It should only be getting a SIGTERM from external source, like systemd trying to shut it down.

Are all the backtraces the same? Are they always preceded by that bad req: std::get: wrong index for variant message? That error should be harmless: Somebody sent a malformed REQ.

Are there any other configurations that make it different from non-crashing instances?

Thanks!

[camalolo]

Got a similar error with the current master, not sure if that helps :

2024-11-06 20:16:34.513 (4938227.289s) [Websocket ]INFO| [64713] Connect from 127.0.0.1 compression=Y sliding=Y 2024-11-06 20:16:34.707 (4938227.483s) [Websocket ]INFO| [64713] Disconnect from 127.0.0.1 (0/-) UP: 0b (-nan% compressed) DN: 479b (30.5% compressed)

Loguru caught a signal: SIGTERM Stack trace: 10 0x55620ceeec31 /home/laurent/crypto/strfry(+0x2dc31) [0x55620ceeec31] 9 0x7ff502167305 __libc_start_main + 133 8 0x7ff50216724a /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7ff50216724a] 7 0x55620ceee6cb /home/laurent/crypto/strfry(+0x2d6cb) [0x55620ceee6cb] 6 0x55620cf0d1e1 /home/laurent/crypto/strfry(+0x4c1e1) [0x55620cf0d1e1] 5 0x55620d16aeb2 /home/laurent/crypto/strfry(+0x2a9eb2) [0x55620d16aeb2] 4 0x55620d16a91c /home/laurent/crypto/strfry(+0x2a991c) [0x55620d16a91c] 3 0x7ff5024d4517 std::thread::join() + 23 2 0x7ff5021cac33 /lib/x86_64-linux-gnu/libc.so.6(+0x8ac33) [0x7ff5021cac33] 1 0x7ff5021c5e96 /lib/x86_64-linux-gnu/libc.so.6(+0x85e96) [0x7ff5021c5e96] 0 0x7ff50217c050 /lib/x86_64-linux-gnu/libc.so.6(+0x3c050) [0x7ff50217c050] 2024-11-06 20:20:14.763 (4938447.539s) [main thread ]FATL| Signal: SIGTERM

[camalolo]

Ok in my case the problem is this :

2024-11-06 20:31:06.970 ( 0.026s) [main thread ] ERR| Database version too old: 2. Expected version 3 2024-11-06 20:31:06.970 ( 0.027s) [main thread ] ERR| You should 'strfry export' your events, delete (or move) the DB files, and 'strfry import' them

I suppose the SIGTERM actually comes from the system manager that kills the process