Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1568599 - ucarp service script fails
Summary: ucarp service script fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: ucarp
Version: epel7
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-17 21:46 UTC by poky
Modified: 2019-03-13 17:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-24 13:24:40 UTC
Type: Bug


Attachments (Terms of Use)

Description poky 2018-04-17 21:46:00 UTC
Description of problem:
ucarp service script fails (file /usr/libexec/ucarp/ucarp)

Version-Release number of selected component (if applicable):
ucarp-1.5.2.22.el7 (CentOS 7)

How reproducible:
Always

Steps to Reproduce:
1.yum update
  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

2.systemctl status ucarp@vip-001.service

Actual results:
Started with debug bash - changed in file /usr/libexec/ucarp: #! /bin/bash -xv


[root@intraweb ucarp]# systemctl start 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@intraweb ucarp]# journalctl -xe
dub 17 22:45:41 intraweb ucarp[31983]: + echo -n 'Starting common address redundancy protocol daemon: '
dub 17 22:45:41 intraweb ucarp[31983]: Starting common address redundancy protocol daemon: + get_files vip-001
dub 17 22:45:41 intraweb ucarp[31983]: + _cfg=vip-001
dub 17 22:45:41 intraweb ucarp[31983]: find ${CONFDIR} -maxdepth 1 -type f -name "vip-${_cfg}.conf"         -printf "%f\n" |
dub 17 22:45:41 intraweb ucarp[31983]: ++ find /etc/ucarp -maxdepth 1 -type f -name vip-vip-001.conf -printf '%f\n'
dub 17 22:45:41 intraweb ucarp[31983]: ++ egrep '^vip-[[:digit:]]+\.conf$'
dub 17 22:45:41 intraweb ucarp[31983]: ++ LC_COLLATE=C
dub 17 22:45:41 intraweb ucarp[31983]: ++ sort
dub 17 22:45:41 intraweb ucarp[31983]: + FILES=
dub 17 22:45:41 intraweb ucarp[31983]: + '[' -z '' ']'
dub 17 22:45:41 intraweb ucarp[31983]: + /usr/bin/logger -p daemon.notice -t ucarp 'no virtual addresses are configured in /
dub 17 22:45:41 intraweb ucarp[31983]: + failure

Expected results:
ucarp to start and work

Additional info:
1. Bug in line nr 14 in file /usr/libexec/ucarp/ucarp,
set new variable in file /etc/ucarp/vip-001.conf for password.

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

Old line:
FILES=`find ${CONFDIR} -maxdepth 1 -type f -name "vip-${_cfg}.conf" \

New (corrected) line:
FILES=`find ${CONFDIR} -maxdepth 1 -type f -name "${_cfg}.conf" \

2. Set new variable in file /etc/ucarp/vip-001.conf:
PASSFILE="/etc/ucarp/vip-001.pwd"

3. Create new file for password variable:
echo "MySecretpassword" >/etc/ucarp/vip-001.pwd

4. Restart service:
systemctl restart ucarp@vip-001.service

Comment 1 Gwyn Ciesla 2018-04-24 13:24:40 UTC
File is correct on fresh installs, but since it's marked config noreplace, it has to be manually corrected on existing installs.

Comment 2 Imran Haider 2018-12-07 18:07:34 UTC
Just did a fresh install on CentOS 7.6 and this bug still exists.
OS: CentOS Linux release 7.6.1810 (Core)
Pkg ver: ucarp-1.5.2-22.el7.x86_64

Comment 3 David Schlenk 2019-03-13 17:08:03 UTC
Note to future me and anyone else that stumbles across this:

This is how to interact with ucarp interfaces now:
systemctl status ucarp@001.service

This is apparently how it was done prior to the current release:
systemctl status ucarp@vip-001.service

So if you upgrade ucarp, notice the rpmnew file and decide you want to get current, be sure to stop your existing service(s) with the old syntax before moving the rpmnew file in place. Then move the rpmnew file in place and start the service(s) with the new syntax.


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