这看起来很奇怪。我使用 Bacula 和 BareOS 已有 10 多年了，但现在一个系统出现了奇怪的行为，我不知道原因，也不知道该如何修复。
当它运行每日备份时，它运行良好，直到到达 BackupCatalog 作业，该作业配置为在其他所有操作之后运行。
这项工作看起来已成功终止（表中的 JobStatus=T list jobs）：
*list jobs
...
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
| JobId | Name | Client | StartTime | Type | Level | JobFiles | JobBytes | JobStatus |
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
...
| 5,475 | BackupCatalog | kantor-fd | 2019-12-04 02:56:40 | B | F | 21 | 27,364,860 | T |
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
但是，在messages日志文件中我没有看到最后一项作业的常规摘要。日志文件的结尾如下：
19-Nov 02:32 kantor-dir JobId 5398: shell command: run BeforeJob "/usr/lib/bareos/scripts/make_catalog_backup.pl Kantor"
19-Nov 02:33 kantor-dir JobId 5398: Start Backup JobId 5398, Job=BackupCatalog.2019-11-18_23.10.00_10
19-Nov 02:33 kantor-dir JobId 5398: Using Device "FileStorage" to write.
19-Nov 02:33 kantor-sd JobId 5398: Volume "Kantor-2018-01-08_08:48:50" previously written, moving to end of data.
19-Nov 02:33 kantor-sd JobId 5398: Ready to append to end of Volume "Kantor-2018-01-08_08:48:50" size=4716094462
19-Nov 02:33 kantor-sd JobId 5398: Elapsed time=00:00:05, Transfer rate=5.663 M Bytes/second
就这样。注意，RunAfterJob 脚本似乎没有被执行。但如果我手动执行它，它就会起作用（导出的目录数据库文件会被删除）。然而，这并不是唯一一个使用 RunAfterJob 脚本的作业。
我期望它最后会显示类似这样的内容。所有其他工作都有：
19-Nov 02:32 kantor-dir JobId 5397: Bareos kantor-dir 16.2.6 (02Jun17):
Build OS: x86_64-pc-linux-gnu debian Debian GNU/Linux buster/sid
JobId: 5397
Job: FTP.2019-11-18_23.05.00_09
...
FD termination status: OK
SD termination status: OK
Termination: Backup OK
19-Nov 02:32 kantor-dir JobId 5397: Begin pruning Jobs older than 1 month 10 days .
...
此外，导演的身份看起来很奇怪：
*status dir
kantor-dir Version: 16.2.6 (02 June 2017) x86_64-pc-linux-gnu debian Debian GNU/Linux buster/sid
Daemon started 03-Dec-19 11:10. Jobs: run=4, running=1 mode=0 db=mysql
Heap: heap=135,168 smbytes=222,459 max_bytes=236,758 bufs=543 max_bufs=594
Scheduled Jobs:
...
====
Running Jobs:
Console connected at 04-Dec-19 09:03
JobId Level Name Status
======================================================================
5475 Full BackupCatalog.2019-12-03_23.10.00_08 has terminated
====
Terminated Jobs:
JobId Level Files Bytes Status Finished Name
====================================================================
...
5471 Incr 6,591 7.499 G OK 03-Dec-19 23:15 termsrv
5472 Incr 427 11.37 G OK 03-Dec-19 23:44 1C
5473 Incr 3 3.198 G OK 04-Dec-19 02:56 Oracle
5474 Incr 5,797 2.600 G OK 04-Dec-19 02:56 FTP
Client Initiated Connections (waiting for jobs):
...
====
也就是说，该作业在“正在运行的作业”中列出，但显示已终止。它没有列在“已终止的作业”中，好像主管仍有事要完成。
它在这个状态下挂起了六个小时。我还看到时间上有些奇怪（表中和日志文件中的 StartTime 相差半个小时，但是系统date和 MySQLselect NOW();是同步的）。
导演重启后，导演状态看起来更加合适：
Running Jobs:
Console connected at 04-Dec-19 09:06
No Jobs running.
====
No Terminated Jobs.
这一切都始于两周前。如果我让它挂起，所有后续计划的作业将无限期地等待这个卡住的作业，这意味着不会执行任何备份。
我觉得这可能是此作业的 RunAfterJob 脚本的问题，但它是标准附带的脚本。如果我手动运行，它会起作用。作业定义本身也是标准附带的，唯一的修改是我在 FileSet 中添加了 compression=GZIP，但我每次都这样做，这从未导致任何问题。
需要注意什么？如何解决？
更新：
问题消失了。我不明白为什么。备份至少可以工作两天。似乎没有出现任何问题。
答案1
看来它被配置为在作业备份结束时通过电子邮件发送引导文件BackupCatalog：
Write Bootstrap = "|/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \" -s \"Bootstrap for Job %j\" root@localhost"
如果服务器上的电子邮件发送功能未配置，它将卡住。如果电子邮件发送功能受阻但随后在服务器外部进行了修复，它将突然解开，并且没有任何明显的迹象表明发生了什么变化。这似乎是我的情况。
通过删除它，Write Bootstrap问题就完全避免了。（该作业将按照JobDefs引用DefaultJob模板中的配置写入本地引导文件。）
这是 BareOS 的一个缺陷，它没有解释可能出现的问题，也没有将其记录为问题并采取进一步行动。它只是卡住了。真糟糕。很遗憾，它也是那样配置的默认情况下。