Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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. 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
>
>
> Yes, it is defined in sys/socket.h header but is not actually
> implemented by Zyxel's firmware. However, Bacula does not need to be
> fixed, because Bacula's code uses accept4() in an absolutely correct
> manner. This is either a Zyxel firmware bug or whoever compiled (or
> corss-compiled?) Bacula for the platform used the wrong headers. So, I
> disagree with a Bacula workaround. The fix should be either compiling
> Bacula with the correct headers or else file a bug report with Zyxel.
>
>
>>
>> #ifdef HAVE_ACCEPT4
>> fd = accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);
>> if (fd >= 0 || errno != ENOSYS) {
>> return fd;
>> }
>> /* fallback to using accept upon ENOSYS */
>> #endif /* HAVE_ACCEPT4 */
>> fd = accept(sockfd, addr, addrlen);
>>
>> __Martin
>>
>>
>>> On Fri, 1 Mar 2019 17:14:02 +0100, Kern Sibbald said:
>>> 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_ACCEPT4 1
>>>
>>> If it does, then comment that line out (// at the beginning of the line
>>> or simply deleting the line).
>>>
>>> Then the build should work.
>>>
>>> On 3/1/19 3:14 PM, Andrea Venturoli wrote:
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 party, additional, unofficial
packages.
bye & Thanks
av.
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>>
>>> ___
>>> Bacula-users mailing list
>>> Bacula-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>
>> ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 script from a separate thread, that's the only difference between that and accept4(). Whatever problem is being avoided by using accept4() on linux 2.6.32+, is presumably still alive and well on every other supported platform? Dima ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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. something like
Yes, it is defined in sys/socket.h header but is not actually
implemented by Zyxel's firmware. However, Bacula does not need to be
fixed, because Bacula's code uses accept4() in an absolutely correct
manner. This is either a Zyxel firmware bug or whoever compiled (or
corss-compiled?) Bacula for the platform used the wrong headers. So, I
disagree with a Bacula workaround. The fix should be either compiling
Bacula with the correct headers or else file a bug report with Zyxel.
#ifdef HAVE_ACCEPT4
fd = accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);
if (fd >= 0 || errno != ENOSYS) {
return fd;
}
/* fallback to using accept upon ENOSYS */
#endif /* HAVE_ACCEPT4 */
fd = accept(sockfd, addr, addrlen);
__Martin
On Fri, 1 Mar 2019 17:14:02 +0100, Kern Sibbald said:
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_ACCEPT4 1
If it does, then comment that line out (// at the beginning of the line
or simply deleting the line).
Then the build should work.
On 3/1/19 3:14 PM, Andrea Venturoli wrote:
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 party, additional, unofficial packages.
bye & Thanks
av.
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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(sockfd, addr, addrlen, SOCK_CLOEXEC);
if (fd >= 0 || errno != ENOSYS) {
return fd;
}
/* fallback to using accept upon ENOSYS */
#endif /* HAVE_ACCEPT4 */
fd = accept(sockfd, addr, addrlen);
__Martin
> On Fri, 1 Mar 2019 17:14:02 +0100, Kern Sibbald said:
>
> 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_ACCEPT4 1
>
> If it does, then comment that line out (// at the beginning of the line
> or simply deleting the line).
>
> Then the build should work.
>
> On 3/1/19 3:14 PM, Andrea Venturoli wrote:
> > 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 party, additional, unofficial packages.
> >
> > bye & Thanks
> > av.
> >
> >
> > ___
> > Bacula-users mailing list
> > Bacula-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bacula-users
> >
>
>
>
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 handled this situation in the same way that Bacula has been handling similar situations for almost 20 years now ... Best regards, Kern On 3/1/19 7:11 PM, Dmitri Maziuk via Bacula-users wrote: > 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 >> implemented. It seems the header file being used (sys/socket.h) does >> not match the installed library. >> >> Nevertheless, accept4() is a convenience extension and it doesn't >> seem worth potentially breaking some platforms to save one or two >> fcntl() calls. > > My point was, what are the chances the programmer had no clue about > accept4() being non-portable non-POSIX gunk in the first place? One > wonders what flags are actually being passed to the call in question. > > (Yes, I've built GNU stuff on SPARC Solaris with Sun Studio. That's > where contempt for libtool and "gunk" pronunciation of "GNU C" comes > from.) > > Dima > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 implemented. It seems the header file being used (sys/socket.h) does not match the installed library. Nevertheless, accept4() is a convenience extension and it doesn't seem worth potentially breaking some platforms to save one or two fcntl() calls. My point was, what are the chances the programmer had no clue about accept4() being non-portable non-POSIX gunk in the first place? One wonders what flags are actually being passed to the call in question. (Yes, I've built GNU stuff on SPARC Solaris with Sun Studio. That's where contempt for libtool and "gunk" pronunciation of "GNU C" comes from.) Dima ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 version will not contain the new code. The fix I proposed below, if it works, would allow the new code to function correctly. Best regards, Kern On 3/1/19 5:26 PM, Andrea Venturoli wrote: > 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 >> not contain a line that reads: >> >> #define HAVE_ACCEPT4 1 >> >> If it does, then comment that line out (// at the beginning of the line >> or simply deleting the line). >> >> Then the build should work > > Thanks, but I said I just changed the sources, so I'm ok now. > I just wrote to report this. > > > > bye > av. > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 not contain a line that reads: #define HAVE_ACCEPT4 1 If it does, then comment that line out (// at the beginning of the line or simply deleting the line). Then the build should work Thanks, but I said I just changed the sources, so I'm ok now. I just wrote to report this. bye av. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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_ACCEPT4 1 If it does, then comment that line out (// at the beginning of the line or simply deleting the line). Then the build should work. On 3/1/19 3:14 PM, Andrea Venturoli wrote: > 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 party, additional, unofficial packages. > > bye & Thanks > av. > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 the extension (accept4) is not on every platform, the implementation of it as far as I can see is correct. 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 implemented. It seems the header file being used (sys/socket.h) does not match the installed library. Nevertheless, accept4() is a convenience extension and it doesn't seem worth potentially breaking some platforms to save one or two fcntl() calls. Kind regards, Josh Fisher Best regards, Kern On 2/28/19 8: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 not competent enough to understand the difference between the two; I cannot also tell why it is defined and why it does not work. It looks like accept(4) is a gnu-ism that takes a couple of convenience flags and falls back on accept() if the flags are 0. Arguably it's an error between the programmer's chair and keyboard: by using a non-standard extension that at best saves you a couple of extra lines of code, they lost portability to non-glibc systems including presumable musl-based linux distros. But hey, we don't need portable C: ./configure libtool will figure it all out for us. Dima ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 not competent enough to understand the difference between the two; I cannot also tell why it is defined and why it does not work. It looks like accept(4) is a gnu-ism that takes a couple of convenience flags and falls back on accept() if the flags are 0. Arguably it's an error between the programmer's chair and keyboard: by using a non-standard extension that at best saves you a couple of extra lines of code, they lost portability to non-glibc systems including presumable musl-based linux distros. Taking that programmer's chair and keyboard error a step further... There are only two flags that can be used in the accept4() flags arg, SOCK_NONBLOCK and SOCK_CLOEXEC, setting O_NONBLOCK and/or O_CLOEXEC. AFAIK, the O_CLOEXEC is a Linux-ism introduced in 2.6.23 and so automatically makes it less portable. The O_NONBLOCK simply saves a fcntl() call, so why does accept4() even exist. IMO, the original programmer's chair to keyboard error was made by Gnu. This is a nearly pointless POSIX extension. But hey, we don't need portable C: ./configure libtool will figure it all out for us. Definitely agree with your doubts about libtool. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 party, additional, unofficial packages. bye & Thanks av. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 platform, the implementation of it as far as I can see is correct. At this point, my best assessment is that there is a bug in the Zyxel libraries. Best regards, Kern On 2/28/19 8: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 not competent enough to understand the difference between the >> two; I cannot also tell why it is defined and why it does not work. > > It looks like accept(4) is a gnu-ism that takes a couple of > convenience flags and falls back on accept() if the flags are 0. > Arguably it's an error between the programmer's chair and keyboard: by > using a non-standard extension that at best saves you a couple of > extra lines of code, they lost portability to non-glibc systems > including presumable musl-based linux distros. > > But hey, we don't need portable C: ./configure libtool will figure it > all out for us. > > Dima > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 two; I cannot also tell why it is defined and why it does not work. It looks like accept(4) is a gnu-ism that takes a couple of convenience flags and falls back on accept() if the flags are 0. Arguably it's an error between the programmer's chair and keyboard: by using a non-standard extension that at best saves you a couple of extra lines of code, they lost portability to non-glibc systems including presumable musl-based linux distros. But hey, we don't need portable C: ./configure libtool will figure it all out for us. Dima ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 why it does not work. I understand I'm running on a sort of "unofficial" environment: since it works, I'm fine. I just thought I'd let you know. bye & Thanks av. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
> 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, same SD config file, > > same compilation procedure). > > The daemon starts, but Director cannot connect. > > Setting debug to 1000 I see (as soon as I issue "status storage"): > > > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > >> backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > > > ... (and so on in a loop)... > > > > On a similar NAS (just a little newer), everything works fine. > > > > Any hint on this? > > For the record: > _ I tried upgrading to 9.4.2, but I got the same error; > _ I solved this by changing "baccept" to "accept" (as it was in 7.x) in > bnet_server.c. That suggests the function accept4 was defined at compile time by fails with errno=38 (ENOSYS) at run time. __Martin ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
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 connect. Setting debug to 1000 I see (as soon as I issue "status storage"): backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 backup-xx-sd: bnet_server.c:184-0 Accept=-1 errno=38 > ... (and so on in a loop)... On a similar NAS (just a little newer), everything works fine. Any hint on this? For the record: _ I tried upgrading to 9.4.2, but I got the same error; _ I solved this by changing "baccept" to "accept" (as it was in 7.x) in bnet_server.c. bye av. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
