That makes some sort of sense. The action for reload is "Just" a signal to MAINPID ExecReload=/bin/kill -HUP $MAINPID
I think the failure is a second -HUP signal before the former reload is fully complete. And on a more complex keepalived setup this might also be a longer time-window to trigger. Yet the service files in Xenial and Zesty are identical, and I'd not know one can wait for a signal to be handled. Might even be a systemd fix in Zesty that now "waits" for such to complete. So lessons learned, I seem to be able to reliably trigger it with a head to head restart: "sudo systemctl restart keepalived; sudo systemctl restart keepalived;" Going to my Zesty env to confirm that there. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1644530 Title: keepalived fails to restart cleanly due to the wrong systemd settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1644530/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
