Description of problem: When "keepalived --vrrp -D" starts as MASTER, it does not call the vrrp_instance notify script. This worked correctly in the previous version keepalived-1.2.16. Version-Release number of selected component (if applicable): keepalived-1.2.17-2.fc21.x86_64 How reproducible: Create /etc/keepalived/keepalived.conf with a vrrp_instance that starts in state MASTER with a notify script. Notice that the notify script is not called when keepalived is started. Steps to Reproduce: 1. In /etc/sysconfig/keepalived, set KEEPALIVED_OPTIONS="--vrrp -D" 2. In /etc/keepalived/keepalived.conf, configure a vrrp_instance with state MASTER and a notify script. 3. Actual results: The notify script is not called when keepalived starts. Expected results: The notify script should be called. Additional info: This works correctly in keepalived-1.2.16-1.fc21.x86_64
This is also true when the instance starts in the BACKUP state. I'm not sure whether notify is called when there is a state transition, but it's never getting called at startup.
I just tested a transition from BACKUP to MASTER and then to BACKUP again, and I do not think the notify script is ever called. From the ChangeLog, it appears that there were lots of patches related to notify in the new release. It seems to be completely broken. Regards, Andy
Please check to see if SELinux is enabled. If so, could you look for any AVCs that might be preventing the notify scripts from running? ausearch -m avc
SElinux is disabled: [hero@ti50 ~]$ selinuxenabled && echo YES [hero@ti50 ~]$ grep -w SELINUX /etc/sysconfig/selinux # SELINUX= can take one of these three values: SELINUX=disabled Regards, Andy
FYI, I created an upstream bug report here: https://sourceforge.net/p/keepalived/bugs/14/ Regards, Andy
(In reply to Andrew J. Schorr from comment #5) > FYI, I created an upstream bug report here: > > https://sourceforge.net/p/keepalived/bugs/14/ I am not sure that the upstream maintainer monitors that sourceforge page. Your best bet is to open an issue on the github page [1] and/or contact the mailing list [2]. I will be investigating this problem soon. [1] https://github.com/acassen/keepalived [2] http://lists.sourceforge.net/mailman/listinfo/keepalived-devel
Thanks for redirecting me. I opened an issue on github: https://github.com/acassen/keepalived/issues/156
I did some tests this evening. Just to be clear we're talking about the "notify" script, not the "notify_master" or "notify_backup", right? I was able to get "notify_master" to work, but "notify" did not. In face, my current configuration has two VRRP instances defined and if I specify a notify script in the first instance, the second instance does not even get parsed. Seems like something is broken in the parser. I will continue investigating.
Thanks for following up on this. I'm talking about the "notify" script. Here's my config (as I posted in the github ticket): vrrp_instance firewall { state BACKUP interface lan0.3009 virtual_router_id 66 priority 150 advert_int 1 authentication { auth_type PASS auth_pass pw32wd } virtual_ipaddress { 192.168.1.1/28 brd 192.168.1.63 dev lan0.3004 } notify /etc/keepalived_notify.sh }
I've not verified this yet, but it appears this patch is the root of the problem: https://github.com/acassen/keepalived/commit/5c4177381bee24f9f7fbe33b8dc20c2d9cc2bccb
It was explained on the mailing list that 'notify' now takes a list of script, so what you want to have in keepalived.conf is: notify { /etc/keepalived_notify.sh } That should fix the problem. However, the patch that introduced this feature is causes major incompatibility with existing configurations where 'notify' is a single script. For this reason I am going to revert the patch and rebuild Fedora packages.
That makes sense. This is not a minor release change, and it's not documented. And please see my subsequent remark in the github thread -- there seems to be another bug that causes the notify script to be called twice. Overall, I'd say that this release is not ready yet.
See also this bug: https://github.com/acassen/keepalived/issues/157 Do we want a separate Fedora bugzilla for this?
(In reply to Andrew J. Schorr from comment #13) > See also this bug: > > https://github.com/acassen/keepalived/issues/157 > > Do we want a separate Fedora bugzilla for this? Not necessarily. Let's chase that upstream and see what happens.
keepalived-1.2.17-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/keepalived-1.2.17-4.fc21
keepalived-1.2.17-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/keepalived-1.2.17-4.fc22
Package keepalived-1.2.17-4.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing keepalived-1.2.17-4.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10567/keepalived-1.2.17-4.fc21 then log in and leave karma (feedback).
keepalived-1.2.18-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/keepalived-1.2.18-1.fc22
keepalived-1.2.18-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/keepalived-1.2.18-1.fc21
keepalived-1.2.18-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
keepalived-1.2.18-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.