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-*
...
PIDFILE=/var/run/bacula/${NAME}.${BPORT}.pid
…
/var/run/ is mounted in tmpfs but this filesystem is volatile so dropped on
shutdown and any directories manually created in it are not recreated on
boot. There is no check in the startup scripts that this directory exists
or to create it if it doesn’t.
One solution is to create a new file "/usr/lib/tmpfiles.d/bacula"
(root:root 755) containing a one-liner;
“d /var/run/bacula 2755 root root”
This will create the pid directory on boot. See man tmpfiles.d for details.
I got this tip from
https://serverfault.com/questions/74796/directory-in-var-run-gets-deleted-after-hard-reboot.
This is not quite enough since Bacula still needs to be manually started
from the startup scripts after reboot.
I added --with-systemd to the configure flags and rebuilt to install unit
files. It's also necessary to "make distclean" before the build to clean up
the configure and to do "sudo systemctl enable bacula*" afterwards. Bacula
now starts after reboot.
Best
Chris
On 12 Apr 2022, at 16:00, Martin Simmons <mar...@lispworks.com> wrote:
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
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 Simmons, <mar...@lispworks.com> wrote:
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
$(DESTDIR)$(sbindir)/$$tool ; \
done
# chattr +i $(DESTDIR)$(sbindir)/bsmtp
# chmod 755 $(DESTDIR)$(sbindir)/bsmtp
__Martin
On Tue, 12 Apr 2022 10:10:38 +0100, Chris Wilkinson said:
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 755, mail began to work.
The other bacula utility programs are also installed as root:root, 750.
Regards
Chris Wilkinson
On Sat, 2 Apr 2022, 8:49 am Chris Wilkinson, <winstonia...@gmail.com>
wrote:
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 bacula to sudoers and as a member of the sudo group
whilst trying to debug this but that was dead end which I should undo
now.
Best
Chris
On Fri, 1 Apr 2022, 11:19 pm Martin Simmons, <mar...@lispworks.com>
wrote:
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 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 \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--docdir=/usr/html \
--htmldir=/usr/html \
--enable-smartalloc \
--with-scriptdir=/etc/bacula/scripts \
--with-working-dir=/var/lib/bacula \
--with-pid-dir=/var/run/bacula \
--with-logdir=/var/log/bacula \
--with-postgresql \
--with-archivedir=/mnt/usb \
--with-job-email=root@localhost \
--with-dump-email=root@localhost \
--with-hostname=pi-b \
--with-db-name=bacula \
--with-db-user=bacula \
--with-db-password=++++ \
--with-dir-user=bacula \
--with-dir-group=bacula \
--with-fd-user=root \
--with-fd-group=root \
--with-sd-user=bacula \
--with-sd-group=tape
Regards
Chris Wilkinson
On Fri, 1 Apr 2022, 12:47 pm Martin Simmons, <mar...@lispworks.com>
wrote:
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, 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 group. Changing the daemons and dbcheck
to
755
fixed this.
Does that suggest the make is in error or maybe my choices of
what
user
to run the daemons as is incorrect?
NOTE: I've not built on Raspian, but it looks like you've
missed the
"--with-XXX-user=" options to configure.
In particular, the permissions are designed for the daemons to be
started
as
root, with the -u and -g options controlling the user and group.
The
default
startup scripts do this using information from the configure.
__Martin
_______________________________________________
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
