size of named pipe

Hi All!

I have a problem with named pipes. I'm only able to send 1024 bytes with putpmsg. If I try to send more I get an error (ERANGE).

How can I change the maximum size of named pipes ?
Who is Participating?

Improve company productivity with a Business Account.Sign Up

chris_calabreseConnect With a Mentor Commented:
You probably have to recompile the kernel to change this.  Don't remember what vbl deals with this anymore (used to know back when the default was 512 bytes and we used to change this all the time).
Please look for strbuf in a file called stropts.h

On solaris this can be found in /usr/include/sys/stropts.h
superschlonzAuthor Commented:
I'm using this structure (also tried to set maxlen=len instead of zero).

And I'm sure I was able to send up to about 3000 bytes some days ago. But after a lot of changes in my source code I always get an ERANGE error when sending 2828 bytes.

I wrote a little testprogram to find out how many bytes are accepted and it shows 1024 (for control part which we use).
And it also shows that I can send 5120 bytes for the data part.

For sending the data we use the ctl part and I'm sure that I didn't touch that. OK, now I'll try sending the data in the data part, perhaps it works.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

superschlonzAuthor Commented:
I saw, this would be very much work.

Is it possible to increase the maximum size of the ctl part ?
Maybe you can find your answer here :

This example illustrates a simple loop, with the application reading data from the communications device, then writing the input back to the same device,
echoing all input back over the communications line. The program reads up to 1024 bytes at a time, and then writes the number of bytes just read.

read returns the available data, which can contain fewer than 1024 bytes. If no data is currently available at the stream head, read(2) blocks until data
Simple Stream

#include <sys/fcntl.h>
#include <stdio.h>
  char buf[1024];
  int fd, count;
   if ((fd = open("/dev/ttya", O_RDWR)) < 0) {
   perror("open failed");
  while ((count = read(fd, buf, sizeof(buf))) > 0) {
   if (write(fd, buf, count) != count) {
    perror("write failed");
Pipe devices just aren't designed for this sort of thing.

You need  your writing program to buffer its output so it won't fill the pipe and you need your reading program to keep reading until it gets the whole thing.

Using stdio should solve the buffering problem easily enough.

If the reader knows the size of the structure it needs to read, then things are easy enough on the reading side too (just keep reading until you get the whole thing, as suggested by paulgna).  Otherwise you might need to prepend the structure with its size so the reader knows how much data it should expect to slurp up.
superschlonzAuthor Commented:
Perhaps they aren't designed for that but they support it (at least since 2.6 and ReliantUNIX/SINIX since 5.42).

I cannot replace the mechanism because I need these bands for sending priorized messages (and because the software is very old and very complex).

This complexity was also the reason why I believed why my changes had nothing to do with the messages sent over the pipe. Now that I found it, I was able to reduce the maximum size to about 900 bytes again as was before my changes and it works.

But I'm still interested in increasing the size because I'm sure I'll run into this problem again and will perhaps not be able to do such a small workaround like this time.

I have also seen some kernel parameters for setting the size for ctl and data part of these system calls, but they aren't set int my /etc/system and default to 64kB.
superschlonzAuthor Commented:
I hoped I wouldn't need to do that...
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.