'Couchdb 3.2.2 does not start on boot after instaltion
I had installed the couchdb 3.2.1. The service started automatically on server boot. After upgrading automatically to 3.2.2 all went wrong and i removed 3.2.1 and made a fresh install of 3.2.2. All is working except the start of the service if the server boots. What can i do to fix this? Thank you.
EDIT: Following the suggestion of Honeywild, i confirm that the service is enabled. I reboot the server and the couchdb did not started again. In the log appeared this:
[error] 2022-04-26T12:49:53.718192Z [email protected] <0.3835.0> -------- OS Process died with status: 143
[error] 2022-04-26T12:49:53.719167Z [email protected] <0.3894.0> -------- OS Process died with status: 143
[error] 2022-04-26T12:49:53.838879Z [email protected] <0.3835.0> -------- gen_server <0.3835.0> terminated with reason: {exit_status,143}
[error] 2022-04-26T12:49:53.839013Z [email protected] <0.3835.0> -------- gen_server <0.3835.0> terminated with reason: {exit_status,143}
[error] 2022-04-26T12:49:53.839087Z [email protected] <0.3894.0> -------- gen_server <0.3894.0> terminated with reason: {exit_status,143}
[error] 2022-04-26T12:49:53.839171Z [email protected] <0.3894.0> -------- gen_server <0.3894.0> terminated with reason: {exit_status,143}
[error] 2022-04-26T12:49:53.843963Z [email protected] <0.3835.0> -------- CRASH REPORT Process (<0.3835.0>) with 0 neighbors exited with reason: {exit_status,143} at gen_server:handle_common_reply/8(line:805) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_os_process,init,['Argument__1']}, ancestors: [<0.3834.0>], message_queue_len: 0, links: [<0.279.0>], dictionary: [], trap_exit: false, status: running, heap_size: 987, stack_size: 28, reductions: 5062
[error] 2022-04-26T12:49:53.844450Z [email protected] <0.3835.0> -------- CRASH REPORT Process (<0.3835.0>) with 0 neighbors exited with reason: {exit_status,143} at gen_server:handle_common_reply/8(line:805) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_os_process,init,['Argument__1']}, ancestors: [<0.3834.0>], message_queue_len: 0, links: [<0.279.0>], dictionary: [], trap_exit: false, status: running, heap_size: 987, stack_size: 28, reductions: 5062
[error] 2022-04-26T12:49:53.844742Z [email protected] <0.3894.0> -------- CRASH REPORT Process (<0.3894.0>) with 0 neighbors exited with reason: {exit_status,143} at gen_server:handle_common_reply/8(line:805) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_os_process,init,['Argument__1']}, ancestors: [<0.3893.0>], message_queue_len: 0, links: [<0.279.0>], dictionary: [], trap_exit: false, status: running, heap_size: 987, stack_size: 28, reductions: 8319
[error] 2022-04-26T12:49:53.845669Z [email protected] <0.3894.0> -------- CRASH REPORT Process (<0.3894.0>) with 0 neighbors exited with reason: {exit_status,143} at gen_server:handle_common_reply/8(line:805) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_os_process,init,['Argument__1']}, ancestors: [<0.3893.0>], message_queue_len: 0, links: [<0.279.0>], dictionary: [], trap_exit: false, status: running, heap_size: 987, stack_size: 28, reductions: 8319
[error] 2022-04-26T12:49:53.867452Z [email protected] <0.549.0> -------- gen_server <0.549.0> terminated with reason: killed
[error] 2022-04-26T12:49:53.867542Z [email protected] <0.549.0> -------- gen_server <0.549.0> terminated with reason: killed
[error] 2022-04-26T12:49:53.867706Z [email protected] <0.549.0> -------- CRASH REPORT Process (<0.549.0>) with 0 neighbors exited with reason: killed at gen_server:decode_msg/9(line:475) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_multidb_changes,init,['Argument__1']}, ancestors: [<0.431.0>,couch_replicator_sup,<0.397.0>], message_queue_len: 0, links: [], dictionary: [], trap_exit: true, status: running, heap_size: 2586, stack_size: 28, reductions: 12699
[error] 2022-04-26T12:49:53.867823Z [email protected] <0.549.0> -------- CRASH REPORT Process (<0.549.0>) with 0 neighbors exited with reason: killed at gen_server:decode_msg/9(line:475) <= proc_lib:init_p_do_apply/3(line:226); initial_call: {couch_multidb_changes,init,['Argument..
Then i simple run service couchdb start, and it started without any problem. This kind of problems did not occur in previous couchdb version and usually i simple made upgrade without any problems. I am using Ubuntu 20.04.04 LTS. Any more ideas? Than you.
Solution 1:[1]
There was an update from couchdb that fixed the problem: now version is 3.2.2-2 in ubuntu.
Solution 2:[2]
First of all, check if the systemctl service is enabled, run systemctl is-enabled
sudo systemctl list-unit-files | grep enabled | grep couchdb
or
sudo systemctl list-unit-files --state=enabled | grep couchdb
if the output to a console will be empty, run:
sudo systemctl enable couchdb.service
then check again:
sudo systemctl list-unit-files --state=enabled | grep couchdb
next, if the service has been enabled, you did right, you followed a good practice, which is to identify the error in the logs.
Probably you tried:
sudo journalctl -u couchdb.service
and then you found the error which you mentioned above.
Further research steps can include:
- Disable the systemd service (temporary):
systemctl disable couchdb
- Reboot
- Run the application manually not as a systemd service
/path/to/couchdb
and check a result. - Run the application manually with strace
strace /path/to/couchdb
and check a result.
One more idea:
You have to be sure that the service is started after the network is started
More:
agree and conduct a diagnostic session together to understand what exactly causes this error.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Kaspacainoombro |
Solution 2 |