[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fifo, bogus-fifo, new-fifo

From: Thomas Schwinge
Subject: fifo, bogus-fifo, new-fifo
Date: Sun, 29 Jul 2007 19:40:38 +0200
User-agent: Mutt/1.5.11


What's the story behind `[Hurd]/trans/{,bogus-,new-}fifo.c'?  We're
currently using `fifo.c', however `new-fifo.c' is also being built and
installed and can be used, which I did just today (read below).  Where is
`bogus-fifo.c' stemming from?  Miles, you wrote all three of them.

So, I was trying to get the runit package <http://smarden.org/runit/>
compiled, which is a daemon supervision / control package, like SysV-init
or upstart, just different.  It uses a fifo for communication between the
user (system administrator) and the daemon-controlling helper program
(runsv).  Building it went fine, but the test suite didn't finish
successfully.  I reduced this down to the following:

$ cat test_fifo_open.c
#include <fcntl.h>
#include <stdio.h>

main (int argc, char *argv[])
  int fd;

  fd = open (argv[1], O_WRONLY | O_NDELAY);

  if (fd == -1)
    perror ("open");

  return 0;
$ ./runsv "`pwd`"/service &
[4] 1557
$ showtrans service/supervise/ok
$ ./test_fifo_open service/supervise/ok
$ ./test_fifo_open service/supervise/ok
open: No such device or address
$ ./test_fifo_open service/supervise/ok
open: No such device or address

This open call is supposed to finish successfully everytime invoked, as
it does on GNU/Linux, for example.

Looking at the runsv source code I suspected the problem to be either (a)
in there (unlikely, as it does work on GNU/Linux and a number of other
UNIXy operating systems) or (b) somewhere in glibc's select
implementation (may well be, as there are already a number of as-yet
undebugged reports about select not doing as it should do) or (c) in the
fifo implementation itself.

As it was easy to do and I remembered about `/hurd/new-fifo' in just the
right moment, I did the following:

$ sudo settrans -cp /servers/fifo /hurd/new-fifo --standalone
[Don't forget the --standalone option ``Don't attempt to use a fifo server''
to tell this master fifo server to not reconnect to itself recursively...]
$ kill 1557
[4]   Done                    runsv "`pwd`"/service
$ rm service/supervise/ok
$ settrans -cp service/supervise/ok /hurd/new-fifo
$ ./runsv "`pwd`"/service &
[4] 1617
$ showtrans service/supervise/ok
$ ./test_fifo_open service/supervise/ok
$ ./test_fifo_open service/supervise/ok
$ ./test_fifo_open service/supervise/ok

VoilĂ .  No more ``open: No such device or address''.  Also, the test
suite passed.

Next step: using new-fifo system-wide.  ``sudo cp /hurd/{new-,}fifo''.
Reboot.  The system comes up again.  However:

$ screen
reopen fifo /var/run/screen/S-thomas/1591.ttyp0.leibniz: Resource temporarily 

This is reproducable.  Upon a freshly rebooted system, I was able to get
screen running, but then the new-fifo was running in some busy-loop as I
could hear from the cpu fan spinning up and see from ps' output.  Exiting
screen and restarting it, it comes up with the above error message, with
different file names.

What are other programs that depend on fifos or does someone even know of
a fifo test suite?

Other comments?


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]