Syslog service in pfSense v2.8.1 often stop itself
-
Hello,
I'm experiencing the same problem with a client after updating to 25.07.1
I can also confirm that the problem occurs because we have a remote syslog server under maintenance.
Pf's syslogd should continue to work in this scenario.
I hope a fix is found soon.
Thank you, -
@dennypage Huh. I did not know that.
-
As a workaround you can prevent the syslogd process seeing the connection rejection message from the server by adding firewall walls.
You need to pass the syslog traffic outbound with state set to 'none'. And block the incoming icmp rejection if it's not already blocked.
It then just keeps sending to the server.
-
I have the same problem but with version 25.07.1 of pfsense+ and I am in PCI non-compliance. I think it is not that the remote server is not available for me, it is a bug in the version and it is critical.
-
@vmillan69 said in Syslog service in pfSense v2.8.1 often stop itself:
I think it is not that the remote server is not available for me,
if it is not this specifically -- then more information is likely required to offer any suggestions --
same issue with code reference
https://forum.netgate.com/topic/198418/25.07-unbound-pfblocker-python-syslog/43?_=1758219580156 -
Yes if you're not seeing 'connection refused logged then it's not the same issue. In which case the more info you can give us the better.
-
@stephenw10 said in Syslog service in pfSense v2.8.1 often stop itself:
As a workaround you can prevent the syslogd process seeing the connection rejection message from the server by adding firewall walls.
You need to pass the syslog traffic outbound with state set to 'none'. And block the incoming icmp rejection if it's not already blocked.
It then just keeps sending to the server.
Thanks for the tips
-
Workaround tested on 25.07.1 and working, thanks @stephenw10
Follow for reference:
pfSense LAN: 192.168.50.254/24 Syslog: 192.168.50.253 Syslog port: UDP 1514 ======== Status / System Logs / Settings Remote Logging Options Source Address: LAN IP Protocol: IPv4 Remote log servers: 192.168.50.253:1514 ======== Two floating rules: Action: Pass Interface: LAN Direction: out IPv4 Protocol: UDP Source: 192.168.50.254 Source port: 514 Destination: 192.168.50.253 Destination port: 1514 State type: None Description: WORKAROUND 16362 Action: Block Quick: ticked Interface: LAN Direction: in IPv4 Protocol: ICMP ICMP Subtypes: Destination unreachable Source: 192.168.50.253 Destination: 192.168.50.254 Description: WORKAROUND 16362 -
@mcury I will try your workaround.
I have just applied 25.11 dev and can confirm that it does not solve the syslog issue.
-
Hmm, 25.11-dev has the patched syslogd. Are you still seeing the connection refused message? What's the last thing(s) logged?
-
said in Syslog service in pfSense v2.8.1 often stop itself:
"Service Watchdog" at the moment, maybe a workaround?
I can answer this myself (we rebooted yesterday our syslog server), service watchdog working:
20:43:00 Service Watchdog detected service syslogd stopped. Restarting syslogd (System Logger Daemon) -
@slu How did you implement this - I have never added anything custom to the watchdog.
-
@tsmalmbe not sure what's exactly your question because the custom, but here are the steps:
- install Service_Watchdog package
- Services / Service Watchdog
- Add New Service
- select syslogd
Done :)
-
@slu Yes exactly I needed this very obvious steps clearly spelled out to me :) Thank you.
-
FWIW, I see the service stop randomly, too, but I just use a second HDD mounted on the system drive for my remote logging, so no remote syslog server that might require FW rules. I'd suggest turning on notifications on Watchdog as well so you can check logs.
-
Do you see any errors logged before it stops? I assume you're using syslog-ng locally for the extra disk?
-
@stephenw10 Get back to you later.
-
@stephenw10 Yes, syslog-ng. I'm actually seeing the same type of messages the remote log server users are. Rinse/repeat.
I enabled the watchdog a few days ago but no new notifications of restart since. Notifications are working, as I just enabled the service and waited for the syslogd restart to confirm. From all the repeated entries I see, it seems syslogd get restarted often, far more often than the watchdog would indicate. Some normal, expected actions from syslog-ng? Archiving? Don't know, just blathering. Excuse me if I state the obvious...
Sep 30 17:09:30 syslogd sendto: Connection refused Sep 30 17:09:30 syslogd kernel boot file is /boot/kernel/kernel Sep 30 17:09:29 syslogd exiting on signal 15 Sep 30 17:09:01 syslogd sendto: Connection refused Sep 30 17:09:01 syslogd kernel boot file is /boot/kernel/kernel -
Hmm, good question. It must be syslog-ng restarting. I would expect that to be logged somewhere though...
-
@stephenw10 I see a string of these. The => syslog start is the one watchdog started after I enabled it. Doesn't really seem to follow logic, though...
Daemon exited gracefully, not restarting; exitcode='0'Sep 30 17:08:05 syslogd exiting on signal 15 Sep 30 17:08:00 syslogd sendto: Connection refused Sep 30 17:07:58 supervise/syslog-ng 46549 Daemon exited gracefully, not restarting; exitcode='0' => Sep 30 11:17:02 syslogd kernel boot file is /boot/kernel/kernel Sep 20 08:43:22 syslogd sendto: Connection refused Sep 20 08:43:22 syslogd kernel boot file is /boot/kernel/kernel Sep 20 08:43:22 syslogd exiting on signal 15 Sep 20 08:42:49 syslogd sendto: Connection refused Sep 20 08:42:49 syslogd kernel boot file is /boot/kernel/kernel Sep 20 08:41:53 syslogd exiting on signal 15 Sep 20 08:41:47 syslogd sendto: Connection refused Sep 20 08:41:46 supervise/syslog-ng 39433 Daemon exited gracefully, not restarting; exitcode='0' Sep 19 20:20:27 syslogd kernel boot file is /boot/kernel/kernel Sep 18 05:55:38 supervise/syslog-ng 64260 Daemon exited gracefully, not restarting; exitcode='0' Sep 17 09:05:00 syslogd sendto: Connection refused
