Re: erroneous message from locked-up machine

On Mon, 10 Nov 2003, Michael W. Lucas wrote:

> I came in to work today to find one of my -current machines unable to
> open a pipe.  (This probably had a lot to do with the spamd that went
> stark raving nutters overnight, but that's a separate problem.)  A
> power cycle fixed the problem, but /var/log/messages was filled with:
>
> Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7).
>
> Interesting.
>
> bewilderbeast~;sysctl kern.maxpipekva
> sysctl: unknown oid 'kern.maxpipekva'
> bewilderbeast~;

The following patch fixes this and some nearby style bugs:
- source style bug: line too line
- output style bugs: comma splice, verboseness (helps make the source line
  too long), and kernel message terminated with a ".".

%%%
Index: sys_pipe.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.158
diff -u -2 -r1.158 sys_pipe.c
--- sys_pipe.c	9 Nov 2003 09:17:24 -0000	1.158
+++ sys_pipe.c	10 Nov 2003 17:21:47 -0000
_at__at_ -331,5 +331,5 _at__at_
 	if (error != KERN_SUCCESS) {
 		if (ppsratecheck(&lastfail, &curfail, 1))
-			printf("kern.maxpipekva exceeded, please see tuning(7).\n");
+			printf("kern.ipc.maxpipekva exceeded; see tuning(7)\n");
 		return (ENOMEM);
 	}
%%%

> And tuning(7) doesn't mention this, either.
>
> Is this just work-in-progress, or did someone forget to commit something?

Seems like tuning pipe kva is completely absent in tuning(7) (so the above
message can be shortened further).  You can tune kva generally as documented
there, but the pipe limit is separate.

> PS: Lesson of the day: no pipe KVA, no su.  Great fun on remote
> machines!  :-)

It's interesting that su was the point of failure.  It uses a pipe hack
for IPC.  Otherwise it doesn't use pipes, at least direectly.  It
shouldn't need to use the pipe hack.  My version uses signals instead.

Bruce