Syslogd program specification with . in

X

xtaz

For ages I had used acme.sh sending logs into syslog using the following in /etc/syslog.conf:

Code: 
!-acme.sh
... normal syslog.conf entries ...
!acme.sh
*.*                                             /var/log/acme.log
!*

So this stops a program name of acme.sh logging to any of the normal log files, and then redirects it into /var/log/acme.log.

This worked fine for years. However I've just noticed that it no longer works. I assume since various syslogd commits that happened through june/july in the stable tree for 11.x (I'm running 11.2-STABLE).

If I test with this command, it fails to log anything:

logger -p user.err -t acme.sh test message

If I test with this command (and change the syslog.conf to suit) then it logs everything as expected:

logger -p user.err -t acme test message

So it looks like syslogd is now treating program specifications with a . character in them differently to how it was before. I guess it may be problematic because that's usually how you specify the facility.priority. But it used to work fine......

I've tried escaping the . with a \ and putting quotes around it etc. Doesn't seem to make any difference. Any ideas? Am I missing how you need to configure this, or is it a bug?
 
I would suggest you follow the FreeBSD-stable mailing list and ask questions there.

You'll see there the recent changes made to syslogd and the fallout, for example py-fail2ban.

Look for the thread titled "py-fail2ban turned silent after syslogd rollout (r335059, stable/11)" it may provide some insight.
 
xtaz said:
This worked fine for years. However I've just noticed that it no longer works. I assume since various syslogd commits that happened through june/july in the stable tree for 11.x (I'm running 11.2-STABLE).
Click to expand...
Keep in mind that STABLE is essentially a developer snapshot release. Not as bleeding edge as CURRENT and it should be quite stable, but nonetheless it is possible for weird things to turn up. If you need stability then it might be better to use a RELEASE.

Anyway, can you give us an example of the log entries which slip through? Because I also use a heavily customized syslog.conf roughly comparable to your structure yet haven't noticed any problems. I'm on 11.2 myself though.
 
Ahhh. I am subscribed to the mailing lists. But haven't noticed any threads specifically about syslog. I'll try and find the fail2ban one. Thanks!

And yeah, I've run -STABLE since version 4.1. So I'm no stranger to what that entails. Just this is kind of the point, if it is a bug, it should get fixed for the next RELEASE. You're right though, I should post this to the mailing list rather than here. More chance of a developer noticing it I guess.
 
You must log in or register to reply here.
Back
Top