It links with libpthread. I am told that on the client side it uses a single thread. Would that make a difference?
Also, I forgot to include a link to the *very* long thread on the Amanda list discussing this problem: http://archives.zmanda.com/amanda-archives/viewtopic.php?t=4763&sid=f86451987866cfccc9fe363fe7546a7b Thanks, Michael On Thu, Sep 10, 2009 at 10:09 AM, Stuart Henderson <s...@spacehopper.org>wrote: > On 2009-09-10, Michael Burk <bur...@gmail.com> wrote: > > We have been working for a couple weeks with the Amanda developers to get > > their latest release working on OpenBSD 4.5. Amanda stopped working with > > OpenBSD somewhere around version 2.5.1 (3 years ago). We've been focusing > on > > a failure in the dump process on the client. > > Does newer Amanda use threads? With pthread, stdio will be silently changed > to _non_ blocking. > > > > > > On the client side, dump(8) is started with its output to a blocking > pipe. > > However, dump fails with EAGAIN, which we understand should be > impossible. > > One of the developers outlined the basic process as follows: > > > > In amandad process: > > pipe(pipefd) > > dup2(pipefd[1],b) > > fork > > in the child: > > exec sendbackup process > > dup2(b,c) > > write c #fail with EAGAIN > > > > We added some debug messages to verify that the pipe was blocking. In so > > doing, we discovered that the debug messages "fixed" the problem, and the > > dump succeeded. Narrowing this down, we found the absolute minimal patch > was > > simply inserting the following line before the dup2 above: > > fcntl(datafd, F_GETFL, 0); > > > > This adds to the mystery; why would doing a call that simply returns a > flag > > change the behavior of the program? Is there some side effect of this > call? > > > > We have tried this on several machines (at least the sparc64, amd64 > > platforms), all running 4.5. dump is invoked as follows: > > /sbin/dump dump 0usf 1048576 - /dev/rsd0a > > > > I don't know what other details might be helpful; let me know and I'll > send > > them. > > > > Thank you for any insight. > > > > -- Michael
