Centos 7 couchbase server cannot start the service

Hi There,

I was installed couchbase 4.1 on my centos 7.1 in google cloud. But service is not working to start.

Starting couchbase-server (via systemctl): Failed to start couchbase-server.service: Unit couchbase-server.service
failed to load: No such file or directory.

Someone can help me to fix them.

Thank in advance.

This problem has been reported in Centos 7.2. Please check Support Note http://support.couchbase.com/entries/107347963

You should be able to work around this by using the start/stop script under the couchbase home directory:

/opt/couchbase/etc/couchbase_init.d start

Does anyone know if there is a ticket for this anywhere so I can get updates on when this will be fixed? I see the tech note, but that doesn’t appear to indicate any work is being done to resolve the issue.

The note indicates the bug is in CentOS, not in Couchbase. Tracking for the fix would be there. The issue link appears to be: https://bugs.centos.org/view.php?id=9906

Thanks for the note Matt. A month with no activity in the Red Hat bug base isn’t looking too promising. Since using symlinks in init scripts seemed a bit non-standard I guess I assumed Couchbase would move to standardize that approach so its users wouldn’t get held hostage by the Linux distro’s timeline for fixing the regression.

Also, to help me educate my client to prevent from updating to an unsupported version of an OS that hasn’t been verified with Couchbase, can you help clarify the information found here?
http://developer.couchbase.com/documentation/server/4.1/install/install-platforms.html

Since RHEL version “7” is listed I’m a little unclear on if that specifically means “7.0” or if the lack of a minor version implies any version in the “7.x” series. How can we be sure of the specific supported versions to avoid a premature OS upgrade in the future?

I’m actually familiar with that symlink pattern from other projects/products. Usually the reason is that you don’t have to mess around with more scripting (which is fragile) on package upgrade. Couchbase doesn’t have this issue since we don’t do package upgrade, but it looks like it was hit by the bug nonetheless.

I believe the “7” indicates Couchbase does a full test with the first release (7.0) and then verifies with any updates, relying on RHEL’s forward compatibility within a version. I’ll ask someone authoritative to chime in on this.

Also, I filed MB-17193 to track possibly changing the package, even though it seems pretty clear to me that it’s a bug in RHEL.

Thanks for the ticket Matt and I look forward to seeing more details on how to tell the exact version of each OS that Couchbase has been tested on. I have placed a comment on the ticket which I will paste here as well:

I would agree this is a probably RHEL bug, but would encourage Couchbase to look into a workaround for the sake of your users. My clients don’t really care the technicalities of “whose bug” it is. All they know is the new Couchbase version is “broke” Hopefully RHEL will fix their regression, but in case that takes 6 months, it would be splendid to see a workaround roll out sooner in Couchbase 4.2.
Also, please note the fix documented here works in my limited tests on RHEL 7.2 and Couchbase 4.0. Perhaps this can be part of the fix.
fedora - Failed to start couchbase-server.service: Unit couchbase-server.service failed to load - Unix & Linux Stack Exchange

Thanks for all your reply.
Now Im go back to CentOS 6.5 with CouchBase 4.1 it worked very well. Because I was tried to follow information as you mentions to solve the problem but it doesn’t work.

Thanks.

I have submitted a fix for MB-17193 which will be in either 4.1.1 or 4.1.2.

2 Likes