Bug 28738
| Summary: | IPFW log messages causes syslogd to fsync. | ||
|---|---|---|---|
| Product: | Base System | Reporter: | pkern <pkern> |
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | pkern |
| Priority: | Normal | ||
| Version: | 4.3-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
pkern@utcs.utoronto.ca writes: > >Description: > > syslogd is set to fsync after each klog message. > This results in a lot of disk activity if IPFW is being used > with verbose logging enabled -- an fsync for each IPFW syslog > (and there could be more than one IPFW log message per packet). > But IPFW syslogs use the LOG_SECURITY facility so it's possible > to exempt those messages from being fsync'ed each time. But it may not be the only one using LOG_SECURITY. And if it is now, can you say that for N months in the future? >From unixfreak.org!dima Thu Jul 5 21:13:29 2001 > > pkern@utcs.utoronto.ca writes: > > >Description: > > > > syslogd is set to fsync after each klog message. > > This results in a lot of disk activity if IPFW is being used > > with verbose logging enabled -- an fsync for each IPFW syslog > > (and there could be more than one IPFW log message per packet). > > But IPFW syslogs use the LOG_SECURITY facility so it's possible > > to exempt those messages from being fsync'ed each time. > > But it may not be the only one using LOG_SECURITY. Hi. I made sure to check the kernel sources before trying this change. In 4.3-RELEASE, IPFW messages are the only ones using LOG_SECURITY. So this change would only affect how syslogd behaves when it receives IPFW messages from the kernel. > And if it is now, can you say that for N months in the future? Hmmm, I'm guessing this implies that new code should include comments. Sorry about that. Here's an updated patch. Hope this helps. pk. --- syslogd.c 2001/06/12 08:25:31 1.1 +++ syslogd.c 2001/07/06 22:01:36 @@ -712,6 +712,11 @@ ++p; if ((pri & LOG_FACMASK) == LOG_CONSOLE) flags |= IGN_CONS; + + /* don't fsync for IPFW messages. */ + if ((pri & LOG_FACMASK) == LOG_SECURITY) + flags &= ~SYNC_FILE; + } else { /* kernel printf's come out on console */ flags |= IGN_CONS; IMHO, having LOG_SECURITY fsync for each message is a feature not a bug. However, there is a workaround available to those who don't want disk access for each message using the normal syslogd(8) capabilities. Instead of sending your security messages to a file, security.* /var/log/security You can send them to a _program_ which sends them to a file. For example, we can make a simple buffer so that we need to get 10kB of messages before we write to the file, security.* |/bin/dd obs=10k of=/var/log/security This will prevent the disk write for each message. Other utilities or even a custom program may suit your individual needs better. But I don't feel that messing with any hardcode is appropriate here. The ability to stop the fsync, which I think few people really want, can be done by simply reconfiguring your syslog.conf(5). Does this look workable to you? -- Crist J. Clark cjclark@alum.mit.edu cjclark@jhu.edu cjc@freebsd.org State Changed From-To: open->feedback Feedback on using syslog.conf(5) to stop the constant sync's is requested. Unless there is a good reason why this solution is not sufficient, I'd like to clost this one up. State Changed From-To: feedback->closed Submitter happy with workaround provided. |
syslogd is set to fsync after each klog message. This results in a lot of disk activity if IPFW is being used with verbose logging enabled -- an fsync for each IPFW syslog (and there could be more than one IPFW log message per packet). But IPFW syslogs use the LOG_SECURITY facility so it's possible to exempt those messages from being fsync'ed each time. Fix: --- syslogd.c 2001/06/12 08:25:31 1.1 +++ syslogd.c 2001/06/12 16:39:49 @@ -712,6 +712,8 @@ ++p; if ((pri & LOG_FACMASK) == LOG_CONSOLE) flags |= IGN_CONS; + if ((pri & LOG_FACMASK) == LOG_SECURITY) + flags &= ~SYNC_FILE; } else { /* kernel printf's come out on console */ flags |= IGN_CONS;