Re: [Bacula-users] [Bacula-devel] Bacula release 9.4.2
On 2019-03-05 15:18, John Nemeth wrote: On Mar 4, 10:07am, Kern Sibbald wrote: } } abort() is not portable -- it behaves differently on different } systems. abort() is part of the C standard, which means that it is completely portable. } A segfault is portable, so we use have used it for 20 years now, and it } works fine. Use abort() at your own risk. Derefencing a NULL pointer is undefined behaviour. Modern compilers are getting extremely aggressive in their handling of undefined behaviour. Dereference NULL pointers at your own risk. }-- End of excerpt from Kern Sibbald I have to agree with John here, not only is "abort()" part of the C and POSIX and related standards and highly portable, the use of "*0 = ..." is not. It might be a memory from the early 1980s, straight out of uni and into the fray, but a lot of microprocessors don't consider location "0" to be magical. Cheers, GaryB-) ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Bacula-fd 9.4.2 on Oracle Enterprise Linux 7.6
I've recently reinstalled one of my servers in one of many attempts to get a required work VPN tool working properly, and just this morning reinstalled bacula-client-9.4.2-1.el7.x86_64.rpm and bacula-libs-9.4.2-1.el7.x86_64.rpm from the Bacula.org community repo. The FD runs, but does not appear to be listening on 9102, although it clearly thinks it is: jumpgate:root:~:34 # /opt/bacula/bin/bacula-fd -fP -c /opt/bacula/etc/bacula-fd.conf -d 200 bacula-fd: address_conf.c:274-0 Initaddr 0.0.0.0:9102 jumpgate-fd: jcr.c:131-0 read_last_jobs seek to 192 jumpgate-fd: jcr.c:138-0 Read num_items=0 jumpgate-fd: plugins.c:97-0 load_plugins jumpgate-fd: plugins.c:136-0 Found plugin: name=bpipe-fd.so len=11 jumpgate-fd: fd_plugins.c:1404-0 is_plugin_compatible called jumpgate-fd: fd_plugins.c:1390-0 Loaded plugin: bpipe-fd.so jumpgate-fd: filed.c:270-0 filed: listening on port 9102 jumpgate-fd: bnet_server.c:86-0 Addresses 0.0.0.0:9102 And so does the OS; lsof -i reports: bacula-fd 17970root3u IPv4 362073772 0t0 TCP *:bacula-fd (LISTEN) But: minbar:root:~:13 # /etc/bacula/checkhost -v jumpgate Client jumpgate has address 10.24.32.8 Host jumpgate is alive problem connecting to "jumpgate", port 9102: No route to host at /etc/bacula/checkhost line 118 babylon5:alaric:~:5 $ ping -c3 jumpgate PING jumpgate.caerllewys.net (10.24.32.8) 56(84) bytes of data. 64 bytes from jumpgate.caerllewys.net (10.24.32.8): icmp_seq=1 ttl=64 time=0.271 ms 64 bytes from jumpgate.caerllewys.net (10.24.32.8): icmp_seq=2 ttl=64 time=0.295 ms 64 bytes from jumpgate.caerllewys.net (10.24.32.8): icmp_seq=3 ttl=64 time=0.238 ms --- jumpgate.caerllewys.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 26ms rtt min/avg/max/mdev = 0.238/0.268/0.295/0.023 ms babylon5:alaric:~:6 $ telnet jumpgate 22 Trying 10.24.32.8... Connected to jumpgate.caerllewys.net. Escape character is '^]'. SSH-2.0-OpenSSH_7.4 ^] telnet> quit Connection closed. babylon5:alaric:~:7 $ telnet jumpgate 9102 Trying 10.24.32.8... telnet: Unable to connect to remote host: No route to host babylon5:alaric:~:8 $ The same check works perfectly for other clients also running 9.4.2: minbar:root:~:15 # /etc/bacula/checkhost -v narn Client narn has address 10.24.32.16 Host narn is alive Bacula-FD listening on port 9102 Returning value 0 Is anyone else running 9.4.2, successfully or otherwise, on RHEL/OEL/CentOS 7.6? Has anyone else seen this problem where the FD thinks it is listening on 9102, but is apparently deaf? Is systemd (may it die in darkness) possibly shooting the FD in the foot somehow? I'm at a loss to understand why this is not working. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Director update - F19 to C7
Hi everyone. My director and primary storeage server has just died. I've been able to boot it using a rescue DVD and rsync'd everything off so I have all of my config files, backup volumes etc. I also have the latest database backup from before the server died. I am currently building a new Centos 7 box onto which I plan to: 1) install the latest Bacula and Postgresql RPM's. 2) Carry out the Postgresql rebuilt which should be straightforward 3) restore all of the Bacula config's. 4) restore the storeage, bootstraps etc. 5) anything else to bring things up to date 6) resume operations My old box was a Fedora 19 system, again with standard Fedora RPMs. What will I need to do as part of step 5 in order to get things to work? Will I need to update the database structure etc? Cheers Gary ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] S3 cloud backups with limited local cache size
Hi,
I have just upgraded my Bacula to 9.4.2 and wanted to switch from my old
s3fs-based cloud backups to the new S3 cloud support in Bacula. Though,
it doesn't work the way I would like it to work.
I have unlimited space on my S3 bucket and limited space for my local
cache. I have configured bacula to use 1GB volumes with 10MB parts and
to upload each part and truncate cache after upload.
The problem is S3 uploads are slower than the volumes are filled and I
run out of the cache space during backup. And Bacula handling of this
condition is far from being graceful – not only it stopped writing new
volumes, it also stopped uploading the existing ones, so the space won't
ever be freed.
05-Mar 09:24 jajo-dir JobId 15038: Max Volume jobs=1 exceeded. Marking
Volume "Full-0021" as Used.
05-Mar 09:24 jajo-sd JobId 15038: New volume "Full-0021" mounted on
device "S3-Cloud" (/var/spool/bacula/s3) at 05-Mar-2019 09:24.
05-Mar 09:24 jajo-sd JobId 15038: Fatal error: [SF0209] Out of freespace
caused End of Volume "Full-0021" at 53:9289728 on device "S3-Cloud"
(/var/spool/bacula/s3). Write of 64512 bytes got 24576.
05-Mar 09:24 jajo-sd JobId 15038: Elapsed time=00:21:09, Transfer
rate=16.12 M Bytes/second
05-Mar 09:24 jajo-sd JobId 15038: Cloud Upload transfers:
05-Mar 09:24 jajo-sd JobId 15038: Full-0001/part.1 state=done
size=233 B duration=1s
05-Mar 09:24 jajo-sd JobId 15038: Full-0001/part.2 state=done
size=9.999 MB duration=17s
05-Mar 09:24 jajo-sd JobId 15038: Full-0001/part.3 state=done
size=9.999 MB duration=14s
[...]
05-Mar 09:24 jajo-sd JobId 15038: Full-0001/part.84state=done
size=9.999 MB duration=16s
05-Mar 09:24 jajo-sd JobId 15038: Full-0001/part.85state=done
size=9.999 MB duration=12s
05-Mar 09:24 jajo-sd JobId 15038: Error: Full-0001/part.86
state=error size=9.999 MB duration=11s msg=S3_put_object
ERR=AbortedByCallback
05-Mar 09:24 jajo-sd JobId 15038: Error: Full-0001/part.87
state=error size=9.999 MB duration=0s msg=S3_put_object
ERR=AbortedByCallback
05-Mar 09:24 jajo-sd JobId 15038: Error: Full-0001/part.88
state=error size=9.999 MB duration=0s msg=S3_put_object
ERR=AbortedByCallback
[...]
05-Mar 09:27 jajo-sd JobId 15038: Error: Full-0007/part.84
state=error size=9.999 MB duration=0s msg=S3_put_object
ERR=AbortedByCallback
05-Mar 09:27 jajo-sd JobId 15038: Error: Full-0007/part.85
state=error size=9.999 MB duration=1s msg=S3_put_object
ERR=AbortedByCallback
[...]
My storage configuration.
Device {
Name = S3-Cloud
Device Type = Cloud
Cloud = S3-Cloud
Archive Device = /var/spool/bacula/s3
Maximum File Size = 10 MB
Maximum Part Size = 10 MB
Maximum Volume Size = 1 GB
Media Type = CloudVolume
LabelMedia = yes
Random Access = yes
AutomaticMount = yes
RemovableMedia = no
}
Cloud {
Name = S3-Cloud
Driver = "S3"
HostName = "s3.amazonaws.com"
BucketName = ...
AccessKey = ...
SecretKey = ...
Protocol = HTTPS
UriStyle = VirtualHost
Truncate Cache = AfterUpload
Upload = EachPart
Region = ...
MaximumUploadBandwidth = 8MB/s
}
Is there any way to make Bacula wait until enough volumes are uploaded
and removed before writing new ones to the cache? Maybe some virtual
autochanger magic?
Greets,
Jacek
___
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]
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
