reasonable inndf patch?
Uli Zappe
uli at ritual.org
Wed Dec 1 17:51:46 UTC 1999
Hi,
as I've told you I've been plagued by totally irregular and irreproducible
throttlings of innd by innwatch because inndf wrongly reports 0 bytes of free
space (on NEXTSTEP 3.3).
Looking at teh source, you can easily see this stems from the fact that inndf
reports 0 bytes when statfs fails (for whatever reason).
Is it really reasonable to throttle innd because statfs fails (which, at
least on NEXTSTEP, seems to happen arbitrarily)?
Anyway, I applied the following (still NEXTSTEP specific) patch to inndf.c
(inn 2.2.0 released); maybe it's reasonable to do it this way in general?
*** inndf.c.orig Wed Dec 1 16:27:37 1999
--- inndf.c Wed Dec 1 17:05:53 1999
***************
*** 109,122 ****
#define KILOBYTES 1024L
void
Printspace(char *path, BOOL inode, BOOL needpadding)
{
struct STATSTRUC buf;
STATTYPES value;
if (STATFUNCT(path, &buf) != 0) {
! value = 0L; /* if there's an error - free space is zero */
} else {
if (!inode) {
/* this is often the same as just buf.f_bavail */
--- 109,129 ----
#define KILOBYTES 1024L
+ #include <syslog.h>
+ #include <errno.h>
+
void
Printspace(char *path, BOOL inode, BOOL needpadding)
{
struct STATSTRUC buf;
STATTYPES value;
+ char errbuf[BUFSIZ];
if (STATFUNCT(path, &buf) != 0) {
! sprintf(errbuf,"can't report free space: %s",strerror(errno));
! openlog("inndf", LOG_PID|LOG_CONS, LOG_LOCAL1);
! syslog(LOG_ERR, errbuf);
! exit(-1);
} else {
if (!inode) {
/* this is often the same as just buf.f_bavail */
Bye
Uli
_____________________________________________________________________
Uli Zappe E-Mail: uli at ritual.org
(NeXTMail,Mime,ASCII) PGP on request
Lorscher Strasse 5 WWW: -
D-60489 Frankfurt Fon: +49 (69) 9784 0007
Germany Fax: +49 (69) 9784 0042
_____________________________________________________________________
More information about the inn-workers
mailing list