The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=1430
======================================================================
Reported By: manielsen2002
Assigned To:
======================================================================
Project: bacula
Issue ID: 1430
Category: Director
Reproducibility: always
Severity: crash
Priority: normal
Status: closed
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 2009-12-04 19:36 UTC
Last Modified: 2009-12-09 15:14 UTC
======================================================================
Summary: After a job has completed on the server then change
the directory config file and type reload on console directro crashes
Description:
After a recently completed job go into the bacula-dir.conf and make a
change. then save the file and go to bconsole and tell it to reload the
config. The director service will crash. If you restart the service all
is well again.
I can reproduce this problem every time. I can performn a reload numerous
times without problem as long as a job has not completed prior after the
last service restart.
======================================================================
----------------------------------------------------------------------
(0004850) ebollengier (administrator) - 2009-12-09 15:14
http://bugs.bacula.org/view.php?id=1430#c4850
----------------------------------------------------------------------
I'm not able to reproduce your problem on Linux, if the configuration file
is OK, the director shouldn't crash. Using reload command after a completed
Job is used on almost every Bacula installation over the world. It could be
a specific Windows problem, but we don't support the Director on this OS.
You can try to reproduce and fix the problem by yourself and send us a
patch.
The reload command need to be rewritten, this work will be started after
the next main release.
Issue History
Date Modified Username Field Change
======================================================================
2009-12-04 19:36 manielsen2002 New Issue
2009-12-09 15:14 ebollengier Note Added: 0004850
2009-12-09 15:14 ebollengier Status new => closed
======================================================================

The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=1432
======================================================================
Reported By: fs
Assigned To:
======================================================================
Project: bacula
Issue ID: 1432
Category: Storage Daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Resolution: suspended
Fixed in Version:
======================================================================
Date Submitted: 2009-12-08 20:00 UTC
Last Modified: 2009-12-09 10:12 UTC
======================================================================
Summary: Storage daemon fails to build on snow leapard
Description:
Latest laster branch (as of Dec 8 2009) fails to build on a fully patched,
newly installed Mac 10.6 system. Transcript of a build is attached.
Let me know if you need an account on the system, and I can probably
arrange for one.
======================================================================
----------------------------------------------------------------------
(0004847) kern (administrator) - 2009-12-08 22:17
http://bugs.bacula.org/view.php?id=1432#c4847
----------------------------------------------------------------------
It looks to me like you have not loaded all the necessary development
libraries, because apparently the mtio headers are missing or Apple has
moved them to some non-standard directory.
They would be in one of the following places:
<mtio.h>
<sys/mtio.h>
<sys/tape.h>
Note, the above are normally under /usr/include.
----------------------------------------------------------------------
(0004848) kern (administrator) - 2009-12-09 10:12
http://bugs.bacula.org/view.php?id=1432#c4848
----------------------------------------------------------------------
I am not able to duplicate this problem on my Darwin 9.8, so either the
Apple guys changed something or you are missing a header file.
Although we would like to hear about this, it is really a development issue
because it does not concern a released version, so if you have an update or
more information, please send it to the bacula-devel list.
One thing you can do is to look through all the files in /usr/include
(grep) to find the definition of "mtop" and "MTREW" as well as the other
symbols that are not defined.
Issue History
Date Modified Username Field Change
======================================================================
2009-12-08 20:00 fs New Issue
2009-12-08 20:00 fs File Added: 106-build.txt
2009-12-08 22:17 kern Note Added: 0004847
2009-12-08 22:17 kern Status new => feedback
2009-12-09 10:12 kern Note Added: 0004848
2009-12-09 10:12 kern Status feedback => closed
2009-12-09 10:12 kern Resolution open => suspended
======================================================================

The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=1403
======================================================================
Reported By: bobhetzel
Assigned To:
======================================================================
Project: bacula
Issue ID: 1403
Category: File Daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 2009-10-30 18:42 UTC
Last Modified: 2009-12-06 10:10 UTC
======================================================================
Summary: windows directory attributes aren't being set right
during a restore.
Description:
Bacula seems to be changing and adding attributes somewhere for windows
clients when stuff is restored. Directories that have no attributes when
backed up wind up getting them after a restore. Note that attributes are
not the same as ACLs. In this case the server is Centos 5.3 linux but the
client where bacula-fd is running is windows Vista. It seems to be
happening for XP clients as well. The client filesystem is NTFS. I'm not
sure if the problem is in how the data is getting backed up, how it's being
stored in the database, or if it's just getting munged on the restore, so I
hope you can track this down. I suspect you'll see it on your XP test
computer too, but if it is just my environment I'll be happy to generate
debugging output just tell me what levels would be required to get this
info you'd need.
======================================================================
----------------------------------------------------------------------
(0004744) kern (administrator) - 2009-10-30 22:46
http://bugs.bacula.org/view.php?id=1403#c4744
----------------------------------------------------------------------
First, I am not sure that Bacula backs up and restores Windows file
attributes as you are showing here.
Also, I am sorry, but you haven't explained what you are doing. From what
I can deduce, it looks like you backed up a file and then restored it to a
different location.
So that I can understand what you did, please might start by providing your
bacula-dir.conf file, then showing *exactly* the commands you used for the
backup and restore, along with all the Bacula output. Also include an
attribute dump of *all* the parts of the path before and after restoring,
what is shown above appears to be only a partial dump.
Finally, please backup and restore to the same location, and show whether
or not the attributes are different.
----------------------------------------------------------------------
(0004747) bobhetzel (reporter) - 2009-10-30 23:26
http://bugs.bacula.org/view.php?id=1403#c4747
----------------------------------------------------------------------
The "staffdev" is not a file but a directory. I've removed that directory,
then done another restore, this time an in-place restore and uploaded the
bconsole output so you can see what's going on.
----------------------------------------------------------------------
(0004748) bobhetzel (reporter) - 2009-10-30 23:27
http://bugs.bacula.org/view.php?id=1403#c4748
----------------------------------------------------------------------
After re-running that restore, the directory S and R attributes are again
set.
----------------------------------------------------------------------
(0004749) bobhetzel (reporter) - 2009-10-31 00:58
http://bugs.bacula.org/view.php?id=1403#c4749
----------------------------------------------------------------------
You had me doubting myself there (and I'm fine with having some self-doubt)
so I reset the attributes, re-ran the backup with level=Full on my desktop,
then did a restore of the same directory as before, again putting it into
the original location, and once again the attributes had appeared, so it's
clear that in my environment bacula is setting attributes on restore that
weren't set on backup.
----------------------------------------------------------------------
(0004750) kern (administrator) - 2009-10-31 07:18
http://bugs.bacula.org/view.php?id=1403#c4750
----------------------------------------------------------------------
My intent was not in the least to make you doubt anything. If I doubted
what you wrote, I would have closed the bug :-) My intent was to get you
to be precise so that we have everything in hand and can get to the bottom
of this.
----------------------------------------------------------------------
(0004792) bobhetzel (reporter) - 2009-11-06 14:34
http://bugs.bacula.org/view.php?id=1403#c4792
----------------------------------------------------------------------
Did you need anything else from me on this?
----------------------------------------------------------------------
(0004844) ebollengier (administrator) - 2009-12-05 13:15
http://bugs.bacula.org/view.php?id=1403#c4844
----------------------------------------------------------------------
This problem seems to come from the win32_chmod() function backported
between 2.4.3 and 2.4.4.
----------------------------------------------------------------------
(0004845) ebollengier (administrator) - 2009-12-06 10:10
http://bugs.bacula.org/view.php?id=1403#c4845
----------------------------------------------------------------------
It is fixed in master and in 3.0.3. We will release a windows binary that
correct this problem.
You can also apply the attached patch and compile by yourself.
Thanks
Issue History
Date Modified Username Field Change
======================================================================
2009-10-30 18:42 bobhetzel New Issue
2009-10-30 22:46 kern Note Added: 0004744
2009-10-30 22:46 kern Status new => feedback
2009-10-30 23:26 bobhetzel File Added: restore-out.txt
2009-10-30 23:26 bobhetzel Note Added: 0004747
2009-10-30 23:27 bobhetzel Note Added: 0004748
2009-10-31 00:14 bobhetzel File Added: bacula-dir.conf.txt
2009-10-31 00:15 bobhetzel File Added: bacula-filesets.inc
2009-10-31 00:58 bobhetzel Note Added: 0004749
2009-10-31 07:18 kern Note Added: 0004750
2009-11-06 14:34 bobhetzel Note Added: 0004792
2009-12-05 13:15 ebollengier Note Added: 0004844
2009-12-05 13:16 ebollengier Status feedback =>
acknowledged
2009-12-06 10:08 ebollengier File Added:
0001-Fix-1403-about-windows-directory-attributes-not-well.patch
2009-12-06 10:10 ebollengier Note Added: 0004845
2009-12-06 10:10 ebollengier Status acknowledged => closed
======================================================================

A NOTE has been added to this issue.
======================================================================
http://bugs.bacula.org/view.php?id=1403
======================================================================
Reported By: bobhetzel
Assigned To:
======================================================================
Project: bacula
Issue ID: 1403
Category: File Daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
======================================================================
Date Submitted: 2009-10-30 18:42 UTC
Last Modified: 2009-12-05 13:15 UTC
======================================================================
Summary: windows directory attributes aren't being set right
during a restore.
Description:
Bacula seems to be changing and adding attributes somewhere for windows
clients when stuff is restored. Directories that have no attributes when
backed up wind up getting them after a restore. Note that attributes are
not the same as ACLs. In this case the server is Centos 5.3 linux but the
client where bacula-fd is running is windows Vista. It seems to be
happening for XP clients as well. The client filesystem is NTFS. I'm not
sure if the problem is in how the data is getting backed up, how it's being
stored in the database, or if it's just getting munged on the restore, so I
hope you can track this down. I suspect you'll see it on your XP test
computer too, but if it is just my environment I'll be happy to generate
debugging output just tell me what levels would be required to get this
info you'd need.
======================================================================
----------------------------------------------------------------------
(0004744) kern (administrator) - 2009-10-30 22:46
http://bugs.bacula.org/view.php?id=1403#c4744
----------------------------------------------------------------------
First, I am not sure that Bacula backs up and restores Windows file
attributes as you are showing here.
Also, I am sorry, but you haven't explained what you are doing. From what
I can deduce, it looks like you backed up a file and then restored it to a
different location.
So that I can understand what you did, please might start by providing your
bacula-dir.conf file, then showing *exactly* the commands you used for the
backup and restore, along with all the Bacula output. Also include an
attribute dump of *all* the parts of the path before and after restoring,
what is shown above appears to be only a partial dump.
Finally, please backup and restore to the same location, and show whether
or not the attributes are different.
----------------------------------------------------------------------
(0004747) bobhetzel (reporter) - 2009-10-30 23:26
http://bugs.bacula.org/view.php?id=1403#c4747
----------------------------------------------------------------------
The "staffdev" is not a file but a directory. I've removed that directory,
then done another restore, this time an in-place restore and uploaded the
bconsole output so you can see what's going on.
----------------------------------------------------------------------
(0004748) bobhetzel (reporter) - 2009-10-30 23:27
http://bugs.bacula.org/view.php?id=1403#c4748
----------------------------------------------------------------------
After re-running that restore, the directory S and R attributes are again
set.
----------------------------------------------------------------------
(0004749) bobhetzel (reporter) - 2009-10-31 00:58
http://bugs.bacula.org/view.php?id=1403#c4749
----------------------------------------------------------------------
You had me doubting myself there (and I'm fine with having some self-doubt)
so I reset the attributes, re-ran the backup with level=Full on my desktop,
then did a restore of the same directory as before, again putting it into
the original location, and once again the attributes had appeared, so it's
clear that in my environment bacula is setting attributes on restore that
weren't set on backup.
----------------------------------------------------------------------
(0004750) kern (administrator) - 2009-10-31 07:18
http://bugs.bacula.org/view.php?id=1403#c4750
----------------------------------------------------------------------
My intent was not in the least to make you doubt anything. If I doubted
what you wrote, I would have closed the bug :-) My intent was to get you
to be precise so that we have everything in hand and can get to the bottom
of this.
----------------------------------------------------------------------
(0004792) bobhetzel (reporter) - 2009-11-06 14:34
http://bugs.bacula.org/view.php?id=1403#c4792
----------------------------------------------------------------------
Did you need anything else from me on this?
----------------------------------------------------------------------
(0004844) ebollengier (administrator) - 2009-12-05 13:15
http://bugs.bacula.org/view.php?id=1403#c4844
----------------------------------------------------------------------
This problem seems to come from the win32_chmod() function backported
between 2.4.3 and 2.4.4.
Issue History
Date Modified Username Field Change
======================================================================
2009-10-30 18:42 bobhetzel New Issue
2009-10-30 22:46 kern Note Added: 0004744
2009-10-30 22:46 kern Status new => feedback
2009-10-30 23:26 bobhetzel File Added: restore-out.txt
2009-10-30 23:26 bobhetzel Note Added: 0004747
2009-10-30 23:27 bobhetzel Note Added: 0004748
2009-10-31 00:14 bobhetzel File Added: bacula-dir.conf.txt
2009-10-31 00:15 bobhetzel File Added: bacula-filesets.inc
2009-10-31 00:58 bobhetzel Note Added: 0004749
2009-10-31 07:18 kern Note Added: 0004750
2009-11-06 14:34 bobhetzel Note Added: 0004792
2009-12-05 13:15 ebollengier Note Added: 0004844
======================================================================

The following issue has been SUBMITTED.
======================================================================
http://bugs.bacula.org/view.php?id=1431
======================================================================
Reported By: manielsen2002
Assigned To:
======================================================================
Project: bacula
Issue ID: 1431
Category: Director
Reproducibility: always
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 2009-12-04 19:39 UTC
Last Modified: 2009-12-04 19:39 UTC
======================================================================
Summary: If you change director config file and reload and
there is an error in the config file then bacula locks the file
Description:
If you make a mistake in the director config file and save it and then
reload it using bconsole the director errors out the the problems in the
file. Normally I would just correct the mistake and then reload again but
bacula locks the config file so I can save it without stopping the service
first and then fixing the error in the config file and then restarting the
director.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-12-04 19:39 manielsen2002 New Issue
======================================================================

The following issue has been SUBMITTED.
======================================================================
http://bugs.bacula.org/view.php?id=1430
======================================================================
Reported By: manielsen2002
Assigned To:
======================================================================
Project: bacula
Issue ID: 1430
Category: Director
Reproducibility: always
Severity: crash
Priority: normal
Status: new
======================================================================
Date Submitted: 2009-12-04 19:36 UTC
Last Modified: 2009-12-04 19:36 UTC
======================================================================
Summary: After a job has completed on the server then change
the directory config file and type reload on console directro crashes
Description:
After a recently completed job go into the bacula-dir.conf and make a
change. then save the file and go to bconsole and tell it to reload the
config. The director service will crash. If you restart the service all
is well again.
I can reproduce this problem every time. I can performn a reload numerous
times without problem as long as a job has not completed prior after the
last service restart.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-12-04 19:36 manielsen2002 New Issue
======================================================================

The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=1428
======================================================================
Reported By: neuvti
Assigned To:
======================================================================
Project: bacula
Issue ID: 1428
Category: rpms
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Resolution: fixed
Fixed in Version: 3.1.x
======================================================================
Date Submitted: 2009-11-29 21:58 UTC
Last Modified: 2009-12-01 16:19 UTC
======================================================================
Summary: applybaculadate- logwatch script missing / not found
Description:
There aren't official Bacula 3.0.3 rpms for RHEL/CentOS yet, so the one I'm
using is self-built binaries from the official srpm.
Since updating from 3.0.2, I started getting these messages to root's
mail:
----
/etc/cron.daily/0logwatch:
Cannot find shared script applybaculadate
----
After some investigation, I noticed that 3.0.2 (and obviously its
predecessors) had had this file stucture under /etc/log.d:
[root@... etc]# tree -D log.d/
log.d/
|-- [Jan 28 2009] conf
| |-- [Jul 31 10:15] logfiles
| | `-- [Jul 31 0:21] bacula.conf
| `-- [Jul 31 10:15] services
| `-- [Jul 14 22:10] bacula.conf
`-- [Jan 28 2009] scripts
`-- [Jul 31 10:15] services
`-- [Jul 14 22:10] bacula
In 3.0.3 these files above got moved to /etc/logwatch:
[root@... etc]# tree -D logwatch/
logwatch/
|-- [Nov 22 19:33] conf
| |-- [May 24 2008] ignore.conf
| |-- [Nov 22 19:39] logfiles
| | `-- [Nov 22 19:39] bacula.conf
| |-- [May 24 2008] logwatch.conf
| |-- [May 24 2008] override.conf
| `-- [Nov 22 19:34] services
| `-- [Oct 18 12:10] bacula.conf
`-- [Nov 22 2:06] scripts
`-- [Nov 22 19:32] services
`-- [Oct 18 12:10] bacula
This obviously was a correct (but not adequate) change, since the files
seem to be logwatch-related. Previously, I had never seen any
bacula-relates stuff in the daily logwatch output.
The error message quoted above is obviously due to the last row of
/etc/logwatch/conf/services/bacula.conf:
----
Title = "bacula"
# Which logfile group...
LogFile = bacula
*ApplyBaculaDate =
----
I don't know the internals of logwatch, but after a couple of
trial-and-errors I noticed that commenting out that last line of
/etc/logwatch/conf/services/bacula.conf made the daily error message mail
disappear, and the next logwatch run included a long history of completed
bacula jobs. Sounds very much perfect but...
Now, that quick and dirty fix of mine obviously wasn't enough, because
every day the logwatch output contains the full history of all the jobs
that cand be found in the current (non-rotated) log file.
So, the original logwatch message for missing "applybaculadate" script
seems still to be valid, it obviously contains some mechanism to control
that the same jobs won't get reported repeatedly.
======================================================================
----------------------------------------------------------------------
(0004836) kern (administrator) - 2009-12-01 14:23
http://bugs.bacula.org/view.php?id=1428#c4836
----------------------------------------------------------------------
It appears that the original installation location of logwatch was
/etc/log.d. It now seems to be /etc/logwatch. Consequently, I have
changed all the RedHat specs to use logwatch instead of log.d.
This is in the current git repo and will be released in version 3.2.0.
----------------------------------------------------------------------
(0004841) neuvti (reporter) - 2009-12-01 15:16
http://bugs.bacula.org/view.php?id=1428#c4841
----------------------------------------------------------------------
Since 3.2.0 release propably is still in the distant future, and the daily
logwatch error message will hit every RHEL/CentOS user, would it be
possible to publish in the user list
- where to get the "applybaculadate" script if it's missing from the rpm
install
- where in the file tree this script should be put into
Digging this information from git database may be a little difficult task
for the most users.
----------------------------------------------------------------------
(0004842) kern (administrator) - 2009-12-01 16:19
http://bugs.bacula.org/view.php?id=1428#c4842
----------------------------------------------------------------------
To the best of my knowledge the project has not yet published the 3.0.3
rpms, and this problem has been there probably for years, so I don't see
any urgency in publishing this. Feel free to do so if you wish.
I have sent Scott an email asking him when he will publish the 3.0.3 rpms
and advising him of this fix.
Issue History
Date Modified Username Field Change
======================================================================
2009-11-29 21:58 neuvti New Issue
2009-11-30 04:15 Andrey Issue Monitored: Andrey
2009-12-01 14:23 kern Note Added: 0004836
2009-12-01 14:23 kern Status new => closed
2009-12-01 14:23 kern Resolution open => fixed
2009-12-01 14:23 kern Fixed in Version => 3.1.x
2009-12-01 15:16 neuvti Note Added: 0004841
2009-12-01 15:16 neuvti Status closed => feedback
2009-12-01 15:16 neuvti Resolution fixed => reopened
2009-12-01 16:19 kern Note Added: 0004842
2009-12-01 16:19 kern Status feedback => closed
2009-12-01 16:19 kern Resolution reopened => fixed
======================================================================

The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=1421
======================================================================
Reported By: christian_gaul
Assigned To:
======================================================================
Project: bacula
Issue ID: 1421
Category: Director
Reproducibility: random
Severity: minor
Priority: normal
Status: closed
Resolution: unable to duplicate
Fixed in Version:
======================================================================
Date Submitted: 2009-11-20 08:27 UTC
Last Modified: 2009-12-01 14:31 UTC
======================================================================
Summary: Director gets stuck in status "waiting for client
XXX to connect to storage YYY"
Description:
As reported to bacula-devel (maybe it got ignored because it is the wrong
channel) in
http://www.mail-archive.com/bacula-devel@.../msg05382.html
Director running for a couple of weeks, single workstation running 3.0.3 FD
got shut down inbetween the director telling the FD to connect to the SD
and the FD initiating the connection. Director proceeded to keep that job
in waiting status for over 30 hours and was unable to cancel the job via
bconsole. Also, the director being set to 100 concurrent jobs proceeded to
queue new jobs but not actually run any jobs after about 6 hours of the
first job being blocked. The director has multiple SDs with multiple
devices but none of them (after 6 hours) were able to run jobs.
======================================================================
----------------------------------------------------------------------
(0004837) kern (administrator) - 2009-12-01 14:31
http://bugs.bacula.org/view.php?id=1421#c4837
----------------------------------------------------------------------
In general, we are unable to duplicate this kind of problem, unless you are
using TLS, thus it is difficult to fix. In fact, the problem comes from
the fact that Internet networking standards are abused by more and more
switches and other gear. Bacula relies on the OS to inform it when a
connection has been broken, and by Internet standards that should be a
maximum of 2hours and about 15 minutes. If you have configured your system
differently or have network switches that do not respect these standards,
comm lines can drop without the program being informed.
About the only thing we can do to avoid this is to put timeouts that we
control ourselves. However, this is not so simple.
We will look at doing this in future versions.
By the way, providing you have enabled multiple simultaneous Jobs, we have
never seen a case where all of Bacula is blocked because of a single
blocked line.
We are sorry, but with the information provided here, we cannot duplicate
this, and even if we could, very likely it would break down to an OS
problem and will require significant development as I note above.
Issue History
Date Modified Username Field Change
======================================================================
2009-11-20 08:27 christian_gaul New Issue
2009-11-20 08:27 christian_gaul File Added: bacula-report.tar
2009-11-20 08:36 christian_gaul File Added: gcc.version
2009-11-20 08:37 christian_gaul File Added: emerge.info
2009-12-01 14:31 kern Note Added: 0004837
2009-12-01 14:31 kern Status new => closed
2009-12-01 14:31 kern Resolution open => unable to
duplicate
======================================================================