apache
couch_index_compactor errors after migration to 3.3.2
Hi After migration to 3.3.2 each time we shut down couchdb we get plenty of following errors.
[error] 2023-11-13T11:16:52.821626Z couchdb@xxxxxxx <0.6820.1> -------- CRASH REPORT Process (<0.6820.1>) with 0 neighbors exited with reason: killed at gen_server:decode_msg/9(line:481) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_index_compactor,init,['Argument__1']}, ancestors: [<0.6809.1>,<0.6808.1>], message_queue_len: 0, links: [], dictionary: [], trap_exit: true, status: running, heap_size: 987, stack_size: 28, reductions: 463 [error] 2023-11-13T11:16:52.821822Z couchdb@xxxxxxxxx <0.6820.1> -------- CRASH REPORT Process (<0.6820.1>) with 0 neighbors exited with reason: killed at gen_server:decode_msg/9(line:481) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_index_compactor,init,['Argument__1']}, ancestors: [<0.6809.1>,<0.6808.1>], message_queue_len: 0, links: [], dictionary: [], trap_exit: true, status: running, heap_size: 987, stack_size: 28, reductions: 463 error] 2023-11-13T11:16:52.825666Z couchdb@xxxxxxxxxx <0.25628.0> -------- gen_server <0.25628.0> terminated with reason: killed last msg: redacted state: {st,<0.25619.0>,couch_mrview_index,undefined} extra: [] [error] 2023-11-13T11:16:52.825822Z couchdb@xxxxxxxxx <0.25628.0> -------- gen_server <0.25628.0> terminated with reason: killed last msg: redacted state: {st,<0.25619.0>,couch_mrview_index,undefined} extra: []
Is this something we should worry about?
How we could fix those?
Thank you for the awesome work done on the new version!
Description
Steps to Reproduce
Expected Behaviour
Your Environment
- CouchDB version used:
- Browser name and version:
- Operating system and version:
Additional Context
@nicknaychov if that shows up when couchdb is shutting down it's benign. The error message is saying that a few Erlang processes were forcibly killed while they were running index compaction. On restart they should resume just fine.
In general, when the Erlang VM is shutting down it stops its applications, each one of those will stop its supervisors, and each supervisor may wait for its worker processes to stop. But there is also a timeout to avoid the shutdown being blocked, so then if the system was busy, it may trigger the timeout and so the application will then forcibly kill the remaining processes. When that happens a log like that is emitted, which is kind of noisy and messy. What OS are you using and how are you stopping CouchDB, maybe it's something we can fix (increase the timeout?).
Hi I am doing "systemctl stop couchdb" on CentOS Linux release 7.9.2009 (Core) Thank you for the explanation.