Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge upstream commits and improve SNMP conditional compilation #858

Merged
merged 9 commits into from
May 7, 2018

Conversation

pqarmitage
Copy link
Collaborator

No description provided.

Even though the checker process doesn't subscribe to RTNLGRP_LINK
messages, it appears that older kernels (certainly 2.6.32) can
send RTM_NEWLINK (but not RTM_DELLINK) messages. This occurs
when the link is set to up state.

Only the VRRP process is interested in link messages, and so the
checker process doesn't do the necessary initialisation to be able
to handle RTM_NEWLINK messages.

This commit makes the checker process simply discard RTM_NEWLINK
and RTM_DELLINK messages, rather than assuming that if it receives
an RTM_NEWLINK message it must be the VRRP process.

This problem was reported in issue acassen#848 since the checker process
was segfaulting when a new interface was added when the -a command
line option was specified.

Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
Fix commit 8760507 - "Make checker process handle RTM_NEWLINK
messages ..." when building without the VRRP functionality.

Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
net-snmp-config output can include compiler and linker flags that
refer to spec files that were used to build net-snmp but may not
exist on the system building keepalived. That would cause the build
done by configure to test for net-snmp support to fail; in particular
on a Fedora 28 system that doesn't have the redhat-rpm-config package
installed.

This commit checks that any spec files in the compiler and linker
flags returned by net-snmp-config exist on the system building
keepalived, and if not it removes the reference(s) to the spec file(s).

See https://bugzilla.redhat.com/show_bug.cgi?id=1544527 for further
details.

Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
Commit 0a82c30 introduced the error, but it didn't alter the
functionality of the script.

Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
Unnecessary code was being included when some, but not all, SNMP
options were specified. This commit sorts that out.

Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
@pqarmitage pqarmitage merged commit e10bf51 into acassen:beta May 7, 2018
vincentbernat added a commit to vincentbernat/keepalived that referenced this pull request Jun 6, 2020
First, this reverts changes made in acassen#416 (commit 328ec28). With
lldpd, I don't use `--netsnmp-agent-libs --external-libs` and I never
had an issue with Ubuntu 14.04. From my understanding, the code to fix
mangle `NETSNMP_LIBS` to fix issues with Fedora is then not needed
anymore because the issue appears only because of `--external-libs`,
so the code can be removed as well. This was added in acassen#858 (commit
057c279).

Then, this also reverts changes introduced in acassen#1262, notably commit
63fe1f4. Seperating CPPFLAGS from CFLAGS also reorder some flags,
making headers in `/usr/lib/*/perl/*/CORE` used before the ones in
`lib/`. This happens for `parser.h` and leads to this error when
NetSNMP is linked to libperl. This happens with out-of-tree builds
when `-I$(srcdir)/../include -I$(srcdir)/../../lib` is appended too
late.

```
In file included from ../../../keepalived/core/main.c:54:
/usr/lib/x86_64-linux-gnu/perl/5.30/CORE/parser.h:15:5: error: unknown type name ‘YYSTYPE’
   15 |     YYSTYPE val;    /* semantic value */
      |     ^~~~~~~
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant