On 2/20/19 5:23 PM, Andrea Venturoli wrote:
Hello.
I've got such a NAS where I've been running bacula-sd 7.4.0 (self
compiled from sources) for years.
Now I'm trying to upgrade to 9.2.2 (same Director, same SD config file,
same compilation procedure).
The daemon starts, but Director cannot
> On Thu, 28 Feb 2019 11:25:48 +0100, Andrea Venturoli said:
>
> On 2/20/19 5:23 PM, Andrea Venturoli wrote:
> > Hello.
> >
> > I've got such a NAS where I've been running bacula-sd 7.4.0 (self
> > compiled from sources) for years.
> >
> > Now I'm trying to upgrade to 9.2.2 (same Director,
On 2/28/19 2:23 PM, Martin Simmons wrote:
That suggests the function accept4 was defined at compile time by fails with
errno=38 (ENOSYS) at run time.
I don't know what to answer.
I'm not competent enough to understand the difference between the two; I
cannot also tell why it is defined and wh
On 2/28/2019 8:06 AM, Andrea Venturoli wrote:
On 2/28/19 2:23 PM, Martin Simmons wrote:
That suggests the function accept4 was defined at compile time by
fails with
errno=38 (ENOSYS) at run time.
I don't know what to answer.
I'm not competent enough to understand the difference between the t
Hello,
I have just examined the code, and in my view, the code is programmed
perfectly correctly.
I am not entirely sure what "Arguably it's an error between the
programmer's chair and keyboard" means, since it is non-standard
English. However, though the extension (accept4) is not on every
plat
On 3/1/19 12:34 PM, Kern Sibbald wrote:
At this point, my best assessment is that there is a bug in the Zyxel
libraries.
Just to clarify who's NOT to blame: to compile on a Zyxel NAS I had to
install several third party packages (FFP to begin with); so the problem
might lie in those third pa
On 2/28/2019 2:04 PM, Dmitri Maziuk via Bacula-users wrote:
On 2/28/2019 8:06 AM, Andrea Venturoli wrote:
On 2/28/19 2:23 PM, Martin Simmons wrote:
That suggests the function accept4 was defined at compile time by
fails with
errno=38 (ENOSYS) at run time.
I don't know what to answer.
I'm
On 3/1/2019 6:34 AM, Kern Sibbald wrote:
Hello,
I have just examined the code, and in my view, the code is programmed
perfectly correctly.
I am not entirely sure what "Arguably it's an error between the
programmer's chair and keyboard" means, since it is non-standard
English. However, though
Were you careful to run a ./configure ... on the machine you then did
the make on? If Bacula picked up an old Linux created
/src/config.h file that could explain the accept4 error.
In any case, I would make sure that your /src/config.h file does
not contain a line that reads:
#define HAVE_ACCEPT
On 3/1/19 5:14 PM, Kern Sibbald wrote:
Were you careful to run a ./configure ... on the machine you then did
the make on? If Bacula picked up an old Linux created
/src/config.h file that could explain the accept4 error.
Yes.
In any case, I would make sure that your /src/config.h file does
OK. New code was added, because the default accept() has in certain
circumstances undesirable consequences for Bacula (during execution of
scripts, those scripts can inject data into certain file descriptors in
the core code of Bacula). If you have just changed baccept() to
accept(), your binary
On 3/1/2019 10:10 AM, Josh Fisher wrote:
On 3/1/2019 6:34 AM, Kern Sibbald wrote:
At this point, my best assessment is that there is a bug in the Zyxel
libraries.
It is certainly a bug in the Zyxel libraries. The accept4() is throwing
a ENOSYS, meaning that the function is simply not impl
Hello,
From the code, it is *very* clear that the programmer (not me) knew that
the code was not portable. He provided what appears to be correct
#ifdefing to handle the case, including the appropriate modifications to
configure.in to detect whether or not accept4() exists. The programmer
handle
I think the problem is that accept4 might be defined in libc, but not
implemented in the kernel. Hence it will be detected by configure but will
fail at run time.
The code could be improved by calling accept if accept4 fails at run time,
i.e. something like
#ifdef HAVE_ACCEPT4
fd = accept4(so
On 3/4/2019 10:00 AM, Martin Simmons wrote:
I think the problem is that accept4 might be defined in libc, but not
implemented in the kernel. Hence it will be detected by configure but will
fail at run time.
The code could be improved by calling accept if accept4 fails at run time,
i.e. somethi
On 3/4/2019 10:11 AM, Josh Fisher wrote:
... The fix should be either compiling
Bacula with the correct headers or else file a bug report with Zyxel.
Or to use plain accept() and call fcntl() with CLOEXEC. As I understand
it, there can be a race condition if you fire off your pre-(post-?)job
Thanks Josh. I agree with you.
Best regards,
Kern
PS: In any case the user (reporter) found a solution.
On 3/4/19 5:11 PM, Josh Fisher wrote:
>
> On 3/4/2019 10:00 AM, Martin Simmons wrote:
>> I think the problem is that accept4 might be defined in libc, but not
>> implemented in the kernel. H
17 matches
Mail list logo
