Bug 1304390 - ucarp service script fails
Summary: ucarp service script fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: ucarp
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-03 13:26 UTC by Brett Maton
Modified: 2019-08-29 11:21 UTC (History)
6 users (show)

Fixed In Version: ucarp-1.5.2-9.el5 ucarp-1.5.2-9.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-22 03:21:34 UTC


Attachments (Terms of Use)
Patch to init and service scripts (987 bytes, application/mbox)
2016-02-03 13:26 UTC, Brett Maton
no flags Details

Description Brett Maton 2016-02-03 13:26:02 UTC
Created attachment 1120784 [details]
Patch to init and service scripts

Description of problem:
ucarp service script fails

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1. systemctl restart ucarp@vip-201
2. systemctl status ucarp@vip-201
3.

Actual results:

Feb 03 13:20:10 dev01 systemd[1]: Starting Common address redundancy protocol daemon on vip/201...
Feb 03 13:20:10 dev01 ucarp[15503]: /usr/libexec/ucarp/ucarp: line 10: [: =: unary operator expected


Expected results:
ucarp to start and work.

Additional info:
Simply quotes missing around the ${NETWORKING} test.
Patch attached.

Comment 1 Brett Maton 2016-02-03 13:26:58 UTC
Problem also present in EL6 package

Comment 2 poky 2016-03-04 21:37:55 UTC
(In reply to Brett Maton from comment #1)
> Problem also present in EL6 package

I corfirm this older bug in CentOS 7, x86_64, date 2016-03-04.
I tested ucarp (needed) a half year ago. 

How I corrected:

Correct line number 10 /usr/libexec/ucarp/ucarp.

Old line:
[ ${NETWORKING} = "no" ] && exit 0

New (corrected) line:
[ "${NETWORKING}" = "no" ] && exit 0


Please get to readme how start ucarp with systemctl (systemctl start
ucarp@vip-001.service).

Comment 3 Gwyn Ciesla 2016-03-05 17:20:14 UTC
This should work now in EL-7 since ucarp used systemd now.  I'll push this for EL-6 and EL-5.

Comment 4 Fedora Update System 2016-03-05 17:31:06 UTC
ucarp-1.5.2-9.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0944d3fca5

Comment 5 Fedora Update System 2016-03-05 17:31:13 UTC
ucarp-1.5.2-9.el5 has been submitted as an update to Fedora EPEL 5. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-32008dd36f

Comment 6 Fedora Update System 2016-03-06 01:49:26 UTC
ucarp-1.5.2-9.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-32008dd36f

Comment 7 Fedora Update System 2016-03-06 01:51:50 UTC
ucarp-1.5.2-9.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0944d3fca5

Comment 8 Fedora Update System 2016-03-22 03:21:32 UTC
ucarp-1.5.2-9.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2016-03-22 04:53:15 UTC
ucarp-1.5.2-9.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 Roland Kletzing 2017-04-06 06:42:40 UTC
Can't beliebe, but this Problem is back in Epel 7. can someone reopen this Ticket? I don't find an Option.

Comment 11 Roland Kletzing 2017-04-06 06:47:55 UTC
>[reply] [−] Comment 3 Gwyn Ciesla 2016-03-05 12:20:14 EST
>This should work now in EL-7 since ucarp used systemd now.  
>I'll push this for EL-6 and EL-5.

No, ucarp Script in Libexec dir still wring, and being used.

Please also push fix for EL-7

Comment 12 poky 2018-03-31 20:49:51 UTC
Please reopen this bug in /usr/libexec/ucarp/ucarp.

After update CentOS 7 (EPEL repository)- ucarp 1.5.2 - Feb 27 2018:

cp -avx /usr/libexec/ucarp/ucarp /usr/libexec/ucarp/ucarp-20180331
cp -avx /usr/libexec/ucarp/ucarp.rpmnew /usr/libexec/ucarp/ucarp

systemctl restart ucarp@vip-001.service

Job for ucarp@vip-001.service failed because the control process exited with error code. See "systemctl status ucarp@vip-001.service" and "journalctl -xe" for details.

[root@intrawebx ucarp]# systemctl status ucarp@vip-001.serviceucarp@vip-001.service - Common address redundancy protocol daemon, config: vip-vip/001.conf
   Loaded: loaded (/usr/lib/systemd/system/ucarp@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since So 2018-03-31 21:48:14 CEST; 29s ago
  Process: 25311 ExecStart=/usr/libexec/ucarp/ucarp start %i (code=exited, status=1/FAILURE)
 Main PID: 780 (code=exited, status=0/SUCCESS)

bře 31 21:48:14 intrawebx systemd[1]: Starting Common address redundancy protocol daemon, config: vip-vip/001.conf...
bře 31 21:48:14 intrawebx systemd[1]: ucarp@vip-001.service: control process exited, code=exited status=1
bře 31 21:48:14 intrawebx ucarp[25311]: Starting common address redundancy protocol daemon: [SELHALO]
bře 31 21:48:14 intrawebx systemd[1]: Failed to start Common address redundancy protocol daemon, config: vip-vip/001.conf.
bře 31 21:48:14 intrawebx systemd[1]: Unit ucarp@vip-001.service entered failed state.
bře 31 21:48:14 intrawebx systemd[1]: ucarp@vip-001.service failed.

This works:
cp -avx /usr/libexec/ucarp/ucarp-20180331 /usr/libexec/ucarp/ucarp
systemctl start ucarp@vip-001.service

Comment 13 poky 2018-03-31 20:56:38 UTC
Not work version ucarp-1.5.2.22.el7 (CentOS 7).

Comment 14 Erik Logtenberg 2019-01-04 16:08:56 UTC
It is in fact still wrong in Fedora 29

I don't even think the fix suggested by poky is right, as the NETWORKING variable is not even set at all in Fedora 29 by default. So it is just empty (so the == no test would fail anyways).

Comment 15 Vex Mage 2019-08-29 11:20:49 UTC
I found this on SEO and I don't know if this is appropriate however; I just updated the system and ucarp was updated and now my ucarp services are falling across my entire platform. Hopefully this helps someone however; the /usr/libexec/ucarp/ucarp file now expects some subtle but important changes that the previous version did not.

in /etc/ucarp/vip-common.conf set the PASSFILE to something like PASSFILE=/etc/ucarp/passfile
paste the PASSWORD into /etc/ucarp/passfile
next
systemctl disable ucarp@vip-XXX.service where XXX is your digit representation of your VIP
then
systemctl enable ucarp@XXX.service where XXX is your digit representation of your VIP
finally
systemctl restart ucarp@XXX.service should now work as expected.

This may either be a documentation update or a correction to the script in question.

Thank you!

Comment 16 Vex Mage 2019-08-29 11:21:20 UTC
I found this on SEO and I don't know if this is appropriate however; I just updated the system and ucarp was updated and now my ucarp services are falling across my entire platform. Hopefully this helps someone however; the /usr/libexec/ucarp/ucarp file now expects some subtle but important changes that the previous version did not.

in /etc/ucarp/vip-common.conf set the PASSFILE to something like PASSFILE=/etc/ucarp/passfile
paste the PASSWORD into /etc/ucarp/passfile
next
systemctl disable ucarp@vip-XXX.service where XXX is your digit representation of your VIP
then
systemctl enable ucarp@XXX.service where XXX is your digit representation of your VIP
finally
systemctl restart ucarp@XXX.service should now work as expected.

This may either be a documentation update or a correction to the script in question.

Thank you!


Note You need to log in before you can comment on or make changes to this bug.