I thought I was done with this but not quite. Bacula doesn’t start after a
reboot. The reason is that the pid directory is deleted on reboot so the
startup scripts fail. The reason is that the startup scripts define the pid
files location to be "/var/run/bacula/".
/etc/init.d/bacula-*
...
The bug tracker is at https://bugs.bacula.org.
Maybe the best fix is to use $(INSTALL_PROGRAM_ALL) for the tools instead of
$(INSTALL_PROGRAM)?
__Martin
> On Tue, 12 Apr 2022 14:32:34 +0100, Chris Wilkinson said:
>
> It seemed to me like a bug in the makefile. How should I report it? Or
>
It seemed to me like a bug in the makefile. How should I report it? Or
perhaps one of the devs could pick it up?
dbcheck is also affected. This prevents the dir startup script from running.
It all seems to be working now with these changes made.
Chris.
On Tue, 12 Apr 2022, 11:37 am Martin
That sounds like a bug. The Makefile actually contains comments about this,
so someone was thinking about it:
# Allow non-root execution of bsmtp for non-root Directors
install: $(INSTOOLS)
@for tool in ${INSTOOLS} ; do \
$(LIBTOOL_INSTALL) $(INSTALL_PROGRAM) $$tool
Just a final note on this. I found that bsmtp was installed with root:root
750 permissions. The effect of this was that emails were not sent,
presumably because dir runs as user bacula. There were no errors shown or
logged in any of the logs so it was tricky to track down. Once I changed
bsmtp to
Scripts are installed in /etc/init.d but no unit files for systemd were
installed. Consequently, I can start everything with the /usr/sbin/bacula
script but "systemctl start bacula-xxx.service" won't work. These service
files seem to be in the source tar but don't get installed.
I had added user
That looks OK, but how are you running the startup scripts? You mentioned
sudo before, but they should be run directly as root.
__Martin
> On Fri, 1 Apr 2022 15:40:04 +0100, Chris Wilkinson said:
>
> These are the ./configure flags I used. This puts the desired daemon
> user/group in the
These are the ./configure flags I used. This puts the desired daemon
user/group in the startup scripts. I didn't find a --with option to set the
daemon executable permissions that defaults to 750.
#compile
cd $target/bacula-$ver
PREFIX=/usr/sbin
CFLAGS="-g -O2 -Wall" \
./configure \
> On Fri, 1 Apr 2022 21:29:56 +1100, Gary R Schmidt said:
>
> On 01/04/2022 21:13, Chris Wilkinson wrote:
> > I built this from source and found it would not run due to a permissions
> > error with the daemons bacula-* and dbcheck. It seems the make builds
> > them with permissions 750,
On 01/04/2022 21:13, Chris Wilkinson wrote:
I built this from source and found it would not run due to a permissions
error with the daemons bacula-* and dbcheck. It seems the make builds
them with permissions 750, root:root. I run the director as
bacula:bacula, the fd as root:root and sd as
On 01/04/2022 21:13, Chris Wilkinson wrote:
I built this from source and found it would not run due to a permissions
error with the daemons bacula-* and dbcheck. It seems the make builds
them with permissions 750, root:root. I run the director as
bacula:bacula, the fd as root:root and sd as
I built this from source and found it would not run due to a permissions
error with the daemons bacula-* and dbcheck. It seems the make builds them
with permissions 750, root:root. I run the director as bacula:bacula, the
fd as root:root and sd as bacula:tape. User bacula is a member of the sudo
12 matches
Mail list logo
