Re: Issue with priority when issuing SIGHUP

Quentin Armitage <[email protected]> Thu, 20 Sep 2018 12:52:59 +0100
Newsgroups gmane.linux.keepalived.devel
Organization The Armitage family
Message-ID <[email protected]>
--===============5688864946503549452==
Content-Type: multipart/alternative; boundary="=-c/vOGGXOzdsd7E2EKHCZ"


--=-c/vOGGXOzdsd7E2EKHCZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Thu, 2018-09-20 at 11:46 +0100, Paul Gildea wrote:
> Hello,
> 
> I noticed an issue with changing my VRRP config and issuing a SIGHUP
> instead of stopping and restarting the keepalived process, after each
> config change I issue a SIGHUP to update values. Usually this works
> fine but not in the case of changing priorities and decrementing
> using a tracked interface.
> 
> Originally I had a priority of 50 with a tracked interface having a
> decrement value of -7. I bought down the tracked interface and then I
> proceeded to change the priority to 110 and the decrement value to
> -11. The log then indicates that the effective priority changed
> correctly from 100 to 99, everything seems to be fine with the new
> values selected.
> 
> I then brought back up the tracked interface and at this stage there
> is some internal inconsistency because the message in the log states
> "Changing effective priority from 103 to 114", remembering the old -7
> decrement value but the new priority value, and then adds the new
> decrement -11 value to 103 instead of 99. If I bring the tracked
> interface down again the value changes from 114 to 103.
> 
> In general is this method not supported or is this a bug? Should I be
> stopping/starting keepalived each time I change my config?
> 
> Separate but maybe related, I have also noticed an issue sometimes
> that when I start VRRP with an interface as backup and a priority of
> 110, with a decrement set of -11, when it becomes master it actually
> adds the decrement to the priority and goes to 121, I need to look
> into that issue further though.
> 
Paul,

What you describe should be supported, and it looks like a bug. What
you be most helpful is if you could raise an issue at https://github.co
m/acassen/keepalived/issues . It is most helpful if you can include
what version of keepalived you are using (output of keepalived -v), a
copy of your configuration, and in this case diffs showing the changes
in configuration for the reloads.

Quentin Armitage
--=-c/vOGGXOzdsd7E2EKHCZ
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body bgcolor=3D"#ffffff" text=3D"#2e3436" link=3D"#2a76=
c6" vlink=3D"#2e3436"><div>On Thu, 2018-09-20 at 11:46 +0100, Paul Gildea w=
rote:</div><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-lef=
t:2px #729fcf solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><di=
v>Hello,</div><div><br></div><div>I noticed an issue with changing my VRRP =
config and issuing a SIGHUP instead of stopping and restarting the keepaliv=
ed process, after each config change I issue a SIGHUP to update values. Usu=
ally this works fine but not in the case of changing priorities and decreme=
nting using a tracked interface.</div><div><br></div><div>Originally I had =
a priority of 50 with a tracked interface having a decrement value of -7. I=
 bought down the tracked interface and then I proceeded to change the prior=
ity to 110 and the decrement value to -11. The log then indicates that the =
effective priority changed correctly from 100 to 99, everything seems to be=
 fine with the new values selected.</div><div><br></div><div>I then brought=
 back up the tracked interface and at this stage there is some internal inc=
onsistency because the message in the log states "Changing effective priori=
ty from 103 to 114", remembering the old -7 decrement value but the new pri=
ority value, and then adds the new decrement -11 value to 103 instead of 99=
. If I bring the tracked interface down again the value changes from 114 to=
 103.</div><div><br></div><div>In general is this method not supported or i=
s this a bug? Should I be stopping/starting keepalived each time I change m=
y config?</div><div><br></div><div>Separate but maybe related, I have also =
noticed an issue sometimes that when I start VRRP with an interface as back=
up and a priority of 110, with a decrement set of -11, when it becomes mast=
er it actually adds the decrement to the priority and goes to 121, I need t=
o look into that issue further though.</div><div><br></div></div></div></bl=
ockquote><div>Paul,</div><div><br></div><div>What you describe should be su=
pported, and it looks like a bug. What you be most helpful is if you could =
raise an issue at <a href=3D"https://github.com/acassen/keepalived/issues">=
https://github.com/acassen/keepalived/issues</a> . It is most helpful if yo=
u can include what version of keepalived you are using (output of keepalive=
d -v), a copy of your configuration, and in this case diffs showing the cha=
nges in configuration for the reloads.</div><div><br></div><div>Quentin Arm=
itage</div></body></html>
--=-c/vOGGXOzdsd7E2EKHCZ--



--===============5688864946503549452==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5688864946503549452==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

--===============5688864946503549452==--