> I think that the current facility mechanism is a really poor way of > doing this filtering, for two reasons. How else would you differentiate logs from various facilities? The original engineer(s) did a good job with these features (facilities and priorities) and there doesn't seem to be a compelling reason to remove either. > First of all, it's not granular enough. LOG_DAEMON is a clear example > of this. If 24 facilities are not granular enough how many would be? Most Unix servers don't have half this many processes writing logs in the first place. While DAEMON might not be specific AUTH, LPR, USER, NEWS, FTP, NTP, MAIL, and KERN all seem pretty specific and granular. To those I'd add STAT for `df`, `uptime`, `loadavg`, `etherstat`, `iostat`, `nfsstat`, `vmstat` and other SNMP-like info and CRIT for critical alerts. > Secondly, there's no clear standard over what each facility should be > used for, so application developers each decide for themselves which > one they should use. See above, this is good point however, and a good reason to add facilities to the current set. The existing standard is clear enough 90% of the time and functional enough to at least be maintained for backwards compatibility. You can argue against compatibility but I don't think you'll find much support here. I know I wouldn't be interested in an incompatible syslog daemon. > That's why I prefer to filter based on regexp. Filtering is one thing but there are good reasons to write separate channels before filters. For one it's useful to be able to send different facilities (and priorities) to different destinations: /dev/console, loghostA, loghostB, etc. High volume logs may also need to be handled differently than low-volume logs. This functionality should continue to be supported by the daemon directly and not require sysadmins to roll their own. IMHO and YMMV, -- Roger Marquis Roble Systems Consulting http://www.roble.com/
