If pthreads is the issue, then I have two questions:
1) is the behavior of changing stdio to non_blocking when using pthreads
unique to OpenBSD?
2) why would this call fix the problem:
fcntl(datafd, F_GETFL, 0);
does that have other side effects?
Thanks,
Michael
On Thu, Sep 10, 2009 at 10:44 AM, Bob Beck <b...@ualberta.ca> wrote:
> That is almost certainly the problem. Ditch the pthread dependancy and it
> will probably work fine.
>
>
>
> On Thu, Sep 10, 2009 at 10:34 AM, Michael Burk <bur...@gmail.com> wrote:
>
>> 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
