'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:

  1. Disable the systemd service (temporary): systemctl disable couchdb
  2. Reboot
  3. Run the application manually not as a systemd service /path/to/couchdb and check a result.
  4. Run the application manually with strace strace /path/to/couchdband 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