Commit 7384d94e authored by Tomek Mrugalski's avatar Tomek Mrugalski 🛰
Browse files

[support8785] Select interruption by signal is now logged.

  One of the hypotheses for the #8785 issue is mis-handling of
  the SingalInterruptOnSelect exception. This message will
  be printed every time a signal is received during select().

Conflicts:
	src/bin/dhcp4/dhcp4_messages.mes
	src/bin/dhcp4/dhcp4_srv.cc
parent e9c58e3d
......@@ -386,6 +386,10 @@ will not send a response but will instead ignore the packet. The first
argument contains the client and transaction identification information.
The second argument includes the details of the error.
% DHCP4_PACKET_DROP_NO_TYPE packet received on interface %1 dropped, because of missing msg-type option
This is a debug message informing that incoming DHCPv4 packet did not
have mandatory DHCP message type option and thus was dropped.
% DHCP4_PACKET_NAK_0001 %1: failed to select a subnet for incoming packet, src %2, type %3
This error message is output when a packet was received from a subnet
for which the DHCPv4 server has not been configured. The most probable
......@@ -429,6 +433,12 @@ This error message is issued when preparing an on-wire format of the packet
has failed. The first argument identifies the client and the DHCP transaction.
The second argument includes the error string.
% DHCP4_PACKET_RECEIVE_INTERRUPT packet reception interrupted by signal: %1
This informative message indicates that wait for incoming packet was interrupted
by a signal. This is normal behavior when a signal is received and may
happen during reconfiguration, shutdown or when LFC is being terminated.
The server run will attempt to receive packets again.
% DHCP4_PACKET_RECEIVED %1: %2 (type %3) received from %4 to %5 on interface %6
A debug message noting that the server has received the specified type of
packet on the specified interface. The first argument specifies the
......
......@@ -400,8 +400,8 @@ Dhcpv4Srv::run() {
} catch (const SignalInterruptOnSelect) {
// Packet reception interrupted because a signal has been received.
// This is not an error because we might have received a SIGTERM,
// SIGINT or SIGHUP which are handled by the server. For signals
// that are not handled by the server we rely on the default
// SIGINT, SIGHUP or SIGCHILD which are handled by the server. For
// signals that are not handled by the server we rely on the default
// behavior of the system.
LOG_DEBUG(packet4_logger, DBG_DHCP4_DETAIL, DHCP4_BUFFER_WAIT_SIGNAL)
.arg(signal_set_->getNext());
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment