Hello!
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: #v+ $ cat test_fifo_open.c #include <fcntl.h> #include <stdio.h> int 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 starting $ showtrans service/supervise/ok /hurd/fifo $ ./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 #v- 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: #v+ $ 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 starting $ showtrans service/supervise/ok /hurd/new-fifo $ ./test_fifo_open service/supervise/ok $ ./test_fifo_open service/supervise/ok $ ./test_fifo_open service/supervise/ok #v- 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: #v+ $ screen reopen fifo /var/run/screen/S-thomas/1591.ttyp0.leibniz: Resource temporarily unavailable #v- 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? Regards, Thomas
signature.asc
Description: Digital signature
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
