RFC - bootscript error reporting

Bill's LFS Login lfsbill at nospam.dot
Fri Jan 30 09:35:24 PST 2004

On Fri, 30 Jan 2004, Bill's LFS Login wrote:

> On Thu, 29 Jan 2004, Bryan Kadzban wrote:
> > Bill's LFS Login wrote:
> > > I only post conversationally at this time, as the wise thing is to get
> > > one of the guys who dabble in the kernel all the time to provide an
> > > answer. Not a lot of chance of that I think.
> > >
> >
> > Well, I don't "dabble in the kernel all the time", but I can read source
> > fairly well.  Or at least, I'd like to think so.  ;-)
> >
> > In any case, in fs/fifo.c there are these comments inside the VFS open()
> > function for fifos:
> >
> > <quote #1>
> >      /*
> >       *  O_RDONLY
> >       *  POSIX.1 says that O_NONBLOCK means return with the FIFO
> >       *  opened, even when there is no process writing the FIFO.
> >       */
> > </quote #1>
> >
> > <quote #2>
> >      /*
> >       *  O_WRONLY
> >       *  POSIX.1 says that O_NONBLOCK means return -1 with
> >       *  errno=ENXIO when there is no process reading the FIFO.
> >       */
> > </quote #2>
> >
> > <quote #3>
> >      /*
> >       *  O_RDWR
> >       *  POSIX.1 leaves this case "undefined" when O_NONBLOCK is set.
> >       *  This implementation will NEVER block on a O_RDWR open, since
> >       *  the process can at least talk to itself.
> >       */
> > </quote #3>
> >
> > Now, this only applies to O_NONBLOCK.  If O_NONBLOCK is not specified,
> > then an O_RDONLY open will wait_for_partner, and so will O_WRONLY.  I
> > assume that wait_for_partner is what blocks, based on its name.
> Ah! That sparks another little piece of memory. The test involved bash
> scripts. Under normal circumstances, the writer would *not* open
> non-blocking, so that would 'splain it patiently waiting for the reader
> to start up.
> I beginning to think this means I've only got half-heimers disease
> instead of the full-blown version.  ;)
> >
> > Opening the fifo with O_RDWR won't block in any case -- or at least,
> > it'll never call wait_for_partner directly.
> >
> > This is from kernel 2.6.2-rc1.  Take it with a grain of salt, because I
> > didn't look at every function that gets called to see if it can block.
> I'd bet this is not much different from a 2.4 kernel. That's the one I
> tested on. In fact it was for something to do with (B)LFS. I'll search
> the archives tomorrow and refresh my memory.
> >
> > But it looks like opening a fifo for writing will either block, or
> > return -1 and set errno to ENXIO until a reader is available (depending
> > on whether O_NONBLOCK is specified).  In no case does it *appear* that
> > it'll do something like buffering writes.
> That seems silly (not buffering). And I seem to remember otherwise. But
> don't waste more time on a guessing game by me. I'll do my homework
> tomorrow.

Did my homework (albeit tardily) and looks like you are right on, if I
make some assumptions about what bash is doing. Using the quote from the
'man 2 write' below, it seems that bash is doing the handling of the
signal that is returned when he tries to write to a FIFO that has no
reader. From that, I see no suggestion of buffering (other than what
buffering bash provides itself), but do see mention of blocking and
signals. A reasonable conclusion then is that buffering is not done
by the kernel then (although I hope that once both reader and writer are
active it does normal buffering).

I conclude that means for the purposes of the original topic of this thread
(writing to a FIFO at system bootscript time when an error is
encountered - anybody recall that? I almost forgot!  :P ), the FIFO has
the potential of causing a system freeze if: a) a reader is not started
first and bash blocks waiting for it and the system or bootscript is
unable to then start a reader and the situation is *equivalent* to an
inittab entry with "wait"; b) readers and writers are successfully
started but the output location of the reader is not available
(e.g. corrupted FS) but the reader does not terminate (at some point,
regardless of buffering or not, the writer will block waiting for the
reader to dispatch what it has received and the reader can not dispatch
that stuff). Other scenarios?

I would not use a FIFO if *any* feasible alternative can be found.

Thread on different topic starts here,

FIFO discussion gets started here

In the thread, we have that I originally had it backwards, Jeff catches
that and I reply with this.

  >From man 2 write, RETURNS:

    EPIPE  fd is connected to a pipe or socket whose reading  end  is
    closed. When  this  happens the writing process will receive a
    SIGPIPE signal; if it catches, blocks or  ignores  this  the  error
    EPIPE is returned.

  >From man 2 read, RETURNS:

    EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and no
    data was immediately available for reading

  This means the fail on the read side can be avoided if we use
  non-blocking activities.

  So, good catch Jeff!

> I 'preciate you taking an interest and passing on the info.
> Thanks!

NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
Fix line above & use it to mail me direct.

More information about the lfs-dev mailing list