inn patches for MacOS X Server

Russ Allbery rra at
Sun Nov 28 23:37:44 UTC 1999

Miro Jurisic <meeroh at MIT.EDU> writes:

> First of all, it seems like a clean reboot of the machine leaves behind
> the pid file, which subsequently causes the rc script to complain. It
> also seems that the rc script sometimes gets confused and fails to run
> innd in that case -- but I haven't had the time to track that down.

Are you running ctlinnd shutdown before rebooting the system?  You need to
do that for INN to close down cleanly.

> Second, I have tried using suck+innfeed against 2.2.1 and I have seen
> innd sometimes vanish as I ran innfeed. An analysis shows that it's
> dying with SIGSYS (Bad system call). gdb tells me that the stack is:

> #0  0x413df160 in msync ()
> #1  0x12e94 in ICDwriteactive () at icd.c:399
> #2  0x9a90 in ARTpost (cp=0x165170) at art.c:2570
> #3  0x154c8 in NCpostit (cp=0x165170) at nc.c:197
> #4  0x16ee8 in NCproc (cp=0x165170) at nc.c:937
> #5  0x17744 in NCreader (cp=0x165170) at nc.c:1164
> #6  0x10450 in CHANreadloop () at chan.c:929
> #7  0x14cd8 in main (ac=3, av=0xbffffdc4) at innd.c:944
> #8  0x3df4 in _start ()
> #9  0x3cb4 in start ()

> The arguments passed into msync don't look particularly weird:

> (gdb) up
> #1  0x12e94 in ICDwriteactive () at icd.c:399
> 399         if (msync(ICDactpointer, ICDactsize) < 0) {
> (gdb) print ICDactpointer
> $3 = 0x5fb000 "junk 0000000000 0000000001 y\ncontrol 0000000000 
> 0000000001 y\nlocal.test 0000000002 0000000001 
> y\ncomp.sys.mac.programmer.codewarrior 0000000000 0000000001 
> y\nalt.test 0000000062 0000000001 y\n"
> (gdb) print ICDactsize
> $4 = 189

> Any suggestions how I might proceed?

This looks quite a bit like a bug on the operating system to me; I don't
see why that would result in a signaled invalid system call.  It seems
like a reasonable call.  You could try taking out the msync call just to
make sure that's the problem....

> As far as the dev snapshot is concerned, I tried building the 
> 11-22_03 snapshot, and I have the following problem: my system is 
> detected as MMAP_MISSES_WRITES, but msync is
> int   msync __P((caddr_t, size_t));
> however, storage/timecaf/timecaf.c calls msync like this:
> msync(private->mmapbase, private->mmaplen, MS_INVALIDATE);

> Which obviously doesn't work. I have no idea why my msync is weird, 
> but as far as I can tell the third argument is unnecessary on my 
> MacOS X Server:

>       int msync(caddr_t addr, size_t len)

Yeah, the stuff protected by MMAP_MISSES_WRITES #ifdefs didn't account for
the two-argument varient of msync.  I've just committed a fix to that; it
should be in the next snapshot.

Russ Allbery (rra at         <URL:>

More information about the inn-workers mailing list