Increase FIFO size limit

Question

Thanks to the answers to my other question, I now understand that FIFO on Linux, i.e. /dev/xconsole has a buffer limit of 64 KB.

How can I increase this limit to 128 KB?

Apparently, I will need to recompile my kernel. That's fine, but where do I have to change the size limit in the kernel source?

Is it safe to change it, or could it have some side effects on other components?

I am using kernel 3.18.

Answer 1

Since Linux kernel 2.6.35, you can increase the size of a pipe with the F_SETPIPE_SZ fnctl(). Non-privileged users are limited to values between 0 and the current value of the fs.pipe-max-size sysctl (1 MiB by default).

The value you use should be greater than 64 KiB and be a power of 2.

So you could do:

perl -MFcntl -e 'fcntl(STDIN, 1031, 1048576) or die $!' <> /dev/xconsole

(here with F_SETPIPE_SZ hardcoded to its value on my system as that Linux-specific fcntl() is not otherwise available to my version of perl).

Note that that fcntl() doesn't affect /dev/xconsole but the pipe buffer that has been instantiated when /dev/xconsole was open (by syslog and whatever application is reading the messages at the other end, so you'd need to do it at every boot after syslog has been started).

Now, whether that's what you should be doing is another matter. pipes are inter-process communication mechanism. They're not meant to store data. For syslog entries, 64 KiB should be more than enough as it's orders of magnitude greater than your typical log entry.

More likely in your case you've got a problem in that the application reading from /dev/xconsole is not started early enough or is not reading fast enough.

In any case, I would advise against changing the global default pipe size.

That would be done by changing:

#define PIPE_DEF_BUFFERS        16

(expressed in number of 4 KiB pages) to something else in include/linux/pipe_fs_i.h. It's not impossible that other things would need to be modified to reflect the change or that that change would affect other things in unexpected ways.

If you make it a power of 2 that is >= 16, it would be less likely to break things, but beware it may significantly affect global system performances and the scheduling behaviour in particular.