Command line option to show VRRP status #41
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds a new command line option, -s, --vrrp-status, which will
show the status of VRRP instances.
Example output:
VRRP Instance : VI_1
Interface : eth0
Virtual Router ID : 1
State : BACKUP
Virtual IP address : 192.168.2.99
Advertisement interval : 1.00 sec
Preemption : Disabled
Multicast group : 192.168.2.2
Priority : 100
Effective Priority : 100
Master router : 192.168.2.1 priority 150
Master down interval : 3.0
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Signed-off-by: Jonas Johansson <jonasj76@gmail.com>
|
Hi Jonas, If I completly understand the need for such a nice feature, well, I would rather prefer integrating this feature through the future VTY/CLI. Or having the same feature through a TCP listener instead of using signal_handler updating a file. So I close for the moment this request but keep tuned. Such a feature is also available through SNMP which also a good channel to request Keepalived internals. Instead of SNMP a JSON output could be evaluated too. Anyway, thanks for your time working on extensions ! it is always nice to see coders contributing their work ! :) Cheer, |
MiaoheLin
added a commit
to MiaoheLin/keepalived
that referenced
this pull request
Mar 8, 2019
It's unsafe to use syslog in signal_handler,it may cause deadlock: #0 0x00007f7d1242248c in __lll_lock_wait_private () from /lib64/libc.so.6 acassen#1 0x00007f7d1239e3cd in _L_lock_15626 () from /lib64/libc.so.6 acassen#2 0x00007f7d1239b4d3 in malloc () from /lib64/libc.so.6 acassen#3 0x00007f7d1238da5a in open_memstream () from /lib64/libc.so.6 acassen#4 0x00007f7d1240e32a in __vsyslog_chk () from /lib64/libc.so.6 acassen#5 0x00007f7d1240e922 in __syslog_chk () from /lib64/libc.so.6 acassen#6 0x000055691ddd60bf in syslog (__fmt=0x55691dddeb6f "%s", __pri=6) at /usr/include/bits/syslog.h:31 acassen#7 vlog_message (facility=6, format=<optimized out>, args=args@entry=0x7ffe4c1b8900) at logger.c:50 acassen#8 0x000055691ddd6184 in log_message (facility=facility@entry=6, format=format@entry=0x55691dde5d50 "BUG - write to signal_pipe[1] error %s - please report") at logger.c:59 acassen#9 0x000055691ddd5805 in signal_handler (sig=1) at signals.c:100 acassen#10 <signal handler called> acassen#11 0x00007f7d1242248a in __lll_lock_wait_private () from /lib64/libc.so.6 acassen#12 0x00007f7d1239e3cd in _L_lock_15626 () from /lib64/libc.so.6 acassen#13 0x00007f7d1239b4d3 in malloc () from /lib64/libc.so.6 acassen#14 0x00007f7d1238da5a in open_memstream () from /lib64/libc.so.6 acassen#15 0x00007f7d1240e32a in __vsyslog_chk () from /lib64/libc.so.6 acassen#16 0x00007f7d1240e922 in __syslog_chk () from /lib64/libc.so.6 acassen#17 0x000055691ddd60bf in syslog (__fmt=0x55691dddeb6f "%s", __pri=6) at /usr/include/bits/syslog.h:31 acassen#18 vlog_message (facility=6, format=<optimized out>, args=args@entry=0x7ffe4c1b9380) at logger.c:50 acassen#19 0x000055691ddd6184 in log_message (facility=facility@entry=6, format=format@entry=0x55691dde5d50 "BUG - write to signal_pipe[1] error %s - please report") at logger.c:59 acassen#20 0x000055691ddd5805 in signal_handler (sig=17) at signals.c:100 acassen#21 <signal handler called> acassen#22 0x00007f7d12398de4 in _int_malloc () from /lib64/libc.so.6 acassen#23 0x00007f7d1239bf04 in calloc () from /lib64/libc.so.6 acassen#24 0x00007f7d13e5f409 in __nlmsg_alloc () from /lib64/libnl-3.so.200 acassen#25 0x00007f7d13e5f846 in nlmsg_convert () from /lib64/libnl-3.so.200 acassen#26 0x00007f7d13e61daf in nl_recvmsgs_report () from /lib64/libnl-3.so.200 acassen#27 0x00007f7d13e624a9 in nl_recvmsgs () from /lib64/libnl-3.so.200 acassen#28 0x00007f7d13e62511 in nl_wait_for_ack () from /lib64/libnl-3.so.200 acassen#29 0x00007f7d14073ad0 in genl_ctrl_probe_by_name () from /lib64/libnl-genl-3.so.200 acassen#30 0x00007f7d14073ceb in genl_ctrl_resolve () from /lib64/libnl-genl-3.so.200 acassen#31 0x000055691dda0b55 in ipvs_nl_send_message (msg=msg@entry=0x556924f077a0, func=func@entry=0x55691dda0b00 <ipvs_nl_noop_cb>, arg=arg@entry=0x0) at libipvs.c:302 acassen#32 0x000055691dda515f in ipvs_add_laddr (svc=0x55692fc2ac10, laddr=0x5569359d34e0) at libipvs.c:930 acassen#33 0x000055691dd9d273 in ipvs_talk (cmd=cmd@entry=1168, daemonrule=daemonrule@entry=0x0, ignore_error=ignore_error@entry=false) at ipvswrapper.c:255 acassen#34 0x000055691dd9d614 in ipvs_laddr_group_cmd (cmd=cmd@entry=1168, laddr_group=laddr_group@entry=0x556932f1b4e0) at ipvswrapper.c:626 acassen#35 0x000055691dd9f24a in ipvs_laddr_cmd (vs=0x55692fc2ac10, cmd=1168) at ipvswrapper.c:804 acassen#36 ipvs_cmd (cmd=cmd@entry=1168, vs=vs@entry=0x556931f77e70, rs=rs@entry=0x0) at ipvswrapper.c:874 acassen#37 0x000055691dd9b610 in init_service_laddr (vs=0x556931f77e70) at ipwrapper.c:672 acassen#38 init_service_vs (vs=0x556931f77e70) at ipwrapper.c:762 acassen#39 0x000055691dd9baa1 in init_services () at ipwrapper.c:815 acassen#40 0x000055691dd8dc45 in start_check () at check_daemon.c:277 ---Type <return> to continue, or q <return> to quit--- acassen#41 0x000055691dd8dfe5 in reload_check_thread (thread=<optimized out>) at check_daemon.c:399 acassen#42 0x000055691ddd3bde in thread_call (thread=0x7ffe4c1ba010) at scheduler.c:963 acassen#43 launch_scheduler () at scheduler.c:986 acassen#44 0x000055691dd8e1af in start_check_child () at check_daemon.c:522 acassen#45 0x000055691dd89340 in start_keepalived () at main.c:337 acassen#46 keepalived_main (argc=2, argv=<optimized out>) at main.c:1064 acassen#47 0x00007f7d12338455 in __libc_start_main () from /lib64/libc.so.6 acassen#48 0x000055691dd879fe in _start () I wonder if we can use fprintf instead of log_message ? fprintf is safe in signal handler.
|
So far, this feature is not implemented. |
|
The majority of this has been implemented. Sending SIGUSR1 to the keepalived parent process will trigger the writing of A script to trigger this could be along the lines of: so I am not sure that it needs a command line option for keepalived to be able to trigger it. There are now also JSON and B-Bus options as well. |
|
@pqarmitage I don't understand design concept that why I need to send signal to keepalived just I want to know VRRP status. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds a new command line option, -s, --vrrp-status, which will show the status of VRRP instances.
Example output:
VRRP Instance : VI_1 Interface : eth0 Virtual Router ID : 1 State : BACKUP Virtual IP address : 192.168.2.99 Advertisement interval : 1.00 sec Preemption : Disabled Multicast group : 192.168.2.2 Priority : 100 Effective Priority : 100 Master router : 192.168.2.1 priority 150 Master down interval : 3.0