dpinger exiting on signal 15
-
After upgrading to pfSense+ 22.05-RELEASE I noticed a daily error in the gateways log at 23:00 for process dpinger with the message exiting on signal 15. There is another entry in the log for dpinger just before that (but at the same time) with the message:
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr <MyPublicIP> bind_addr <MyPublicIP> identifier "WAN_DHCP "
I thought it might be something with my Netgate 1100 but after upgrading some clients I see it at their sites too. The only packages in common across these systems are apcupsd and cron, and some of them dont have much more than that (maybe email reports or mtr). Everything keeps working fine but it seems something is going on with dpinger and I just wanted to mention it.
I have two gateways configured in routing. There is the DHCP gateway from the ISP where all traffic goes and I have created a second gateway which is forced down with monitoring actions disabled and an internet based monitoring address as sort of a rudimentary means of monitoring my connection.
Does anyone have an idea why dpinger might be crashing? Thanks!
-
@ex1580 said in dpinger exiting on signal 15:
Does anyone have an idea why dpinger might be crashing?
It's not crashing. Signal 15 is SIGTERM, which means that dpinger is being explicitly terminated (killed).
The log message on termination is new. Previously, dpinger would silently exit when terminated, which resulted in a lot of people thinking that dpinger had "crashed."
-
@dennypage Good to know! I suppose I should have taken a closer look at the sigterm message but all I thought was "this is new". I wont worry about it, but if it's normal I am not sure why it is in the log.
-
-
Check log messages surrounding that, what's triggering dpinger to restart?
The WAN interface being reconnected? The modem rebooting for example would cause that.
Steve
-
@stephenw10 It seems to happen when there is a hotplug event on any interface. This would make sense, except that it's an unrelated interface. For example, I have an interface that is plugged directly into a computer and if I restart the computer these events show up in the gateway log for all gateway interfaces.
-
That can happen certainly if an assigned interface changes state. That can trigger a whole number of things depending on what is installed or configured. Generally though it shouldn't be a problem. The logs you see there are not a cause for concern by themselves.
Steve
-