pqarmitage
commented
5 years ago If you are using Linux 2.6.22 or later, keepalived uses a signalfd for the delivery of signals rather than asynchronous signal delivery; this means that processing is not interrupted by a signal being sent to the keepalived process. When running keepalived on Linux prior to 2.6.22 signals are delivered asynchronously to the keepalived processes, but the signal handler simply writes the signal number to a pipe, and that pipe is read synchronously when ready, as notified by epoll_wait() [this is essentially the same as using signalfd, expect that system calls can return EINTR]. The only disadvantage of this approach compared to using signalfd is that system calls can return EINTR, but the code checks for that where necessary.
You suggest: _What if we receive a signal, when keepalived is in the middle of threadfetch. I see a potential for these lists(event and unused list) to get corrupted. This should not happen due to the reasoning set out above.
Continuously sending signals USR1, USR2 or HUP to the parent keepalived process seems a bizarre thing to do, since HUP will just cause keepalived to reload (presumably the same) configuration, and USR1 and USR2 will just overwrite the previous dump file created. Further, signals are not queued (unless sigqueue() is used), and so a backlog of processing the signals cannot build up.
Finally there is a difficulty with sending a DBus signal when SIGUSR1 processing is complete. Both the vrrp and the checker processes process SIGUSR1, and so there is no single point at which it is known that the processing of SIGUSR1 has completed.
Unless there is a compelling reason to change the code, and by all means explain your use case if you want to convince us that adding a DBus signal is beneficial, I do not think that it is worthwhile just for people using very old kernels (RHEL 6 current kernel is 2.6.32, so even that is not affected). If the code were to be changed, I would be inclined, for pre 2.6.22 kernels, to make the parent process send the signal number on a pipe, rather than sending a real signal, so that it functions in much the same way as signalfd.
Describe the issue Can we have a dbus signal for SIGUSR1 and SIGUSR2.This is a feature request and not an issue. This would help applications not to send continuous signals when another signal is handled.
when ever signals are received, keepalived removes nodes from the unused list and adds to the event list.
During thread fetch, nodes are removed from event list, signal handler function is called and added back to the unused list.
What if we receive a signal, when keepalived is in the middle of thread_fetch. I see a potential for these lists(event and unused list) to get corrupted. For now, we can backoff SIGHUP if an earlier SIGHUP is under processing. It would be better if the same thing can be done for SIGUSR1 and SIGUSR2.
To Reproduce Send continuous signals (sighup, sigusr1 and sigusr2)to keepalived
Expected behavior DBUS signal once sigusr1 and sigusr2 is processed.
Keepalived version 2.0.16
Distro (please complete the following information): Debian Stretch, X86
Details of any containerisation or hosted service (e.g. AWS) If keepalived is being run in a container or on a hosted service, provide full details
Configuration file: A full copy of the configuration file, obfuscated if necessary to protect passwords and IP addresses
Notify and track scripts If any notify or track scripts are in use, please provide copies of them
System Log entries Full keepalived system log entries from when keepalived started
Did keepalived coredump? If so, can you please provide a stacktrace from the coredump, using gdb.
Additional context Add any other context about the problem here.