Dear list, my configuration has become pretty complex I admit. And, yes, I am guilty of not paying for a subscription yet. :) However the director process dies every few days and that frustrates me. Would it be of any use for you or me to post director stack traces here?
Currently I'm suffering from this time and again with 17.2: Thread 5 (Thread 0x7f7af2059700 (LWP 53369)): #0 0x00007f7afc4c4b3a in __waitpid (pid=2457, stat_loc=0x7f7af205758c, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29 #1 0x00007f7afdbed614 in signal_handler (sig=7) at signal.c:240 #2 <signal handler called> #3 0x00007f7afdbc3223 in bnet_host2ipaddrs (host=0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, family=0, errstr=0x7f7af2058028) at bnet.c:418 #4 0x00007f7afdbcc8c6 in BSOCK_TCP::open (this=0x7f7ae8020d38, jcr=0x38, name=0x18 <error: Cannot access memory at address 0x18>, host=0x0, service=0x0, port=80, heart_beat=-6148914691236517206, fatal=0x7f7af2058bdc) at bsock_tcp.c:182 #5 0x00007f7afdbcb885 in BSOCK_TCP::connect (this=0x7f7ae8020d38, jcr=0x7f7ae8001078, retry_interval=2, max_retry_time=0, max_retry_time@entry=1, heart_beat=0, heart_beat@entry=-6148914691236517206, name=0x47c561 "Storage daemon", host=0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, service=0x0, port=-1431655766, verbose=false) at bsock_tcp.c:115 #6 0x000000000044522e in connect_to_storage_daemon (jcr=0x7f7ae8001078, retry_interval=<optimized out>, max_retry_time=<optimized out>, verbose=<optimized out>) at sd_cmds.c:118 #7 0x0000000000447f7b in statistics_thread_runner (arg=0x7f7ae8020b68, arg@entry=0x0) at stats.c:233 #8 0x00007f7afdbde2bf in lmgr_thread_launcher (x=0x25731d8) at lockmgr.c:926 #9 0x00007f7afc4bb494 in start_thread (arg=0x7f7af2059700) at pthread_create.c:333 #10 0x00007f7afb75cacf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 This crash happened 3 minutes after the last backup job that wrote 17 TB of data from a hardware server to tapes in a HP MSL tape library with LTO-6 drives. That job finished with warnings… 17-Jan 00:20 bareos-dir JobId 358851: Bareos bareos-dir 17.2.3 (14Aug17): Build OS: x86_64-pc-linux-gnu debian Debian GNU/Linux 8.0 (jessie) JobId: 358851 Job: backup-veeam-vbk.2019-01-15_00.52.08_30 Backup Level: Full Client: "veeam-fd" 17.2.4 (21Sep17) Microsoft Windows Server 2012 Standard Edition (build 9200), 64-bit,Cross-compile,Win64 FileSet: "veeam-vbk" 2018-11-20 10:52:54 Pool: "TapeVeeam" (From Job resource) Catalog: "MyCatalog" (From Client resource) Storage: "Tape" (From Pool resource) Scheduled time: 15-Jan-2019 00:52:08 Start time: 15-Jan-2019 00:52:10 End time: 17-Jan-2019 00:20:43 Elapsed time: 1 day 23 hours 28 mins 33 secs Priority: 10 FD Files Written: 21 SD Files Written: 21 FD Bytes Written: 17,013,997,001,172 (17.01 TB) SD Bytes Written: 17,013,997,004,626 (17.01 TB) Rate: 99547.7 KB/s Software Compression: None VSS: no Encryption: no Accurate: no Volume name(s): BQA503L6|BQA506L6|BQA515L6|BQA507L6|TST005L6|TST048L6|BQA494L6 Volume Session Id: 65 Volume Session Time: 1547499850 Last Volume Bytes: 1,523,225,526,167 (1.523 TB) Non-fatal FD errors: 0 SD Errors: 7 FD termination status: OK SD termination status: OK Termination: Backup OK -- with warnings I appreciate any suggestions. Best regards… …Christoph -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
