When migrating to fedora 16 (from 14) I have to start bacula using systemctl. It works fine with the client and storage daemons but the director service fails. systemctl status bacula-<daemon> shows:
[root@epohost ~]# systemctl status bacula-dir.service bacula-dir.service - Bacula-Director, the Backup-server Loaded: loaded (/lib/systemd/system/bacula-dir.service; enabled) Active: failed since Fri, 29 Jun 2012 23:09:35 +0200; 1min 9s ago Process: 1781 ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u $DIR_USER -g $DIR_GROUP (code=exited, status=1/FAILURE) Process: 1778 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/bacula-dir.service
[root@epohost ~]# systemctl status bacula-sd.service bacula-sd.service - Bacula-StorageDaemon, the storage-server Loaded: loaded (/lib/systemd/system/bacula-sd.service; enabled) Active: active (running) since Fri, 29 Jun 2012 23:09:27 +0200; 1min 42s ago Process: 1205 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 1219 (bacula-sd) CGroup: name=systemd:/system/bacula-sd.service └ 1219 /usr/sbin/bacula-sd -f -c /etc/bacula/bacula-sd.co...
[root@epohost ~]# systemctl status bacula-fd.service bacula-fd.service - Bacula-FileDaemon, a Backup-client Loaded: loaded (/lib/systemd/system/bacula-fd.service; enabled) Active: active (running) since Fri, 29 Jun 2012 23:09:27 +0200; 1min 55s ago Process: 1196 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 1214 (bacula-fd) CGroup: name=systemd:/system/bacula-fd.service └ 1214 /usr/sbin/bacula-fd -f -c /etc/bacula/bacula-fd.co...
Can somebody decipher what is wrong or perhaps suggest a way to diagnose the problem? Starting bacula-dir manually works fine. Maybe this is for the bacula community to answer but I've started here since it may a failure in the rpm package.
Is there any information in /var/log/messages or bacula's log?
What does 'Starting bacula-dir manually' mean? From systemd vs upon boot?
Bill
On 6/29/2012 5:55 PM, Erik P. Olsen wrote:
When migrating to fedora 16 (from 14) I have to start bacula using systemctl. It works fine with the client and storage daemons but the director service fails. systemctl status bacula-<daemon> shows:
[root@epohost ~]# systemctl status bacula-dir.service bacula-dir.service - Bacula-Director, the Backup-server Loaded: loaded (/lib/systemd/system/bacula-dir.service; enabled) Active: failed since Fri, 29 Jun 2012 23:09:35 +0200; 1min 9s ago Process: 1781 ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u $DIR_USER -g $DIR_GROUP (code=exited, status=1/FAILURE) Process: 1778 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/bacula-dir.service
[root@epohost ~]# systemctl status bacula-sd.service bacula-sd.service - Bacula-StorageDaemon, the storage-server Loaded: loaded (/lib/systemd/system/bacula-sd.service; enabled) Active: active (running) since Fri, 29 Jun 2012 23:09:27 +0200; 1min 42s ago Process: 1205 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 1219 (bacula-sd) CGroup: name=systemd:/system/bacula-sd.service └ 1219 /usr/sbin/bacula-sd -f -c /etc/bacula/bacula-sd.co...
[root@epohost ~]# systemctl status bacula-fd.service bacula-fd.service - Bacula-FileDaemon, a Backup-client Loaded: loaded (/lib/systemd/system/bacula-fd.service; enabled) Active: active (running) since Fri, 29 Jun 2012 23:09:27 +0200; 1min 55s ago Process: 1196 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 1214 (bacula-fd) CGroup: name=systemd:/system/bacula-fd.service └ 1214 /usr/sbin/bacula-fd -f -c /etc/bacula/bacula-fd.co...
Can somebody decipher what is wrong or perhaps suggest a way to diagnose the problem? Starting bacula-dir manually works fine. Maybe this is for the bacula community to answer but I've started here since it may a failure in the rpm package.
On 30/06/12 02:35, Bill Shirley wrote:
Is there any information in /var/log/messages or bacula's log?
Nothing decisive.
What does 'Starting bacula-dir manually' mean? From systemd vs upon boot?
From the command line launch bacula-dir
However, I've solved the problem. When launching bacula-dir this way it runs under userID and groupID root. In /etc/sysconfig/bacula-dir they are both set to bacula. Changing those values to root causes bacula-dir to start correctly.
Am 30.06.2012 21:36, schrieb Erik P. Olsen:
On 30/06/12 02:35, Bill Shirley wrote:
Is there any information in /var/log/messages or bacula's log?
Nothing decisive.
What does 'Starting bacula-dir manually' mean? From systemd vs upon boot?
From the command line launch bacula-dir
However, I've solved the problem. When launching bacula-dir this way it runs under userID and groupID root. In /etc/sysconfig/bacula-dir they are both set to bacula. Changing those values to root causes bacula-dir to start correctly.
this is NOT a solution NEVER let any service run as ROOT really NEVER!
On 06/30/2012 12:41 PM, Reindl Harald wrote:
this is NOT a solution NEVER let any service run as ROOT really NEVER!
Yes! These services create special user/group combos to use because they have to be owned by some regular user without special privileges to limit the potential damage a bug can cause. Running them as root bypasses that protection, just as logging into a GUI as root does.
On 30/06/12 21:41, Reindl Harald wrote:
Am 30.06.2012 21:36, schrieb Erik P. Olsen:
On 30/06/12 02:35, Bill Shirley wrote:
Is there any information in /var/log/messages or bacula's log?
Nothing decisive.
What does 'Starting bacula-dir manually' mean? From systemd vs upon boot?
From the command line launch bacula-dir
However, I've solved the problem. When launching bacula-dir this way it runs under userID and groupID root. In /etc/sysconfig/bacula-dir they are both set to bacula. Changing those values to root causes bacula-dir to start correctly.
this is NOT a solution
Well, since it makes bacula run, it IS a solution allthough I admit it IS bad.
NEVER let any service run as ROOT really NEVER!
May be the folks who package bacula should look into this because if you don't change the userID and groupID somehow in /etc/sysconfig/bacula-dir, /etc/sysconfig/bacula-fd and/or /etc/sysconfig/bacula-sd bacula wont start. I'll play with the values to see if I can find a better solution. I'll keep you posted.
Am 30.06.2012 22:33, schrieb Erik P. Olsen:
On 30/06/12 21:41, Reindl Harald wrote:
this is NOT a solution
Well, since it makes bacula run, it IS a solution allthough I admit it IS bad.
dirty workaorund != solution
NEVER let any service run as ROOT really NEVER!
May be the folks who package bacula should look into this because if you don't change the userID and groupID somehow in /etc/sysconfig/bacula-dir, /etc/sysconfig/bacula-fd and/or /etc/sysconfig/bacula-sd bacula wont start. I'll play with the values to see if I can find a better solution. I'll keep you posted
maybe you should file a bugreport or search the real problem?
On 06/30/2012 01:33 PM, Erik P. Olsen wrote:
Well, since it makes bacula run, it IS a solution allthough I admit it IS bad.
No it isn't. It's a work-around that allows bacula to run while ignoring the central issue: you need to find out how to make bacula run correctly while running as user bacula. If the program itself is owned by that user, you may be able to get things going by using the suid bit. It's a tad weird, I know, and I'm not sure it's a Good Idea. However, if user bacula only has normal privileges, it's *probably* safe.
On 06/30/2012 01:42 PM, Reindl Harald wrote:
dirty workaorund != solution
You and I don't always agree, but on this we're on the same page. Running a service as root without trying to find out what's wrong is just as bad as turning off SELinux whenever a program crashes, even though there aren't any alerts or other evidence that it's part of the problem.
On 30/06/12 22:43, Joe Zeff wrote:
On 06/30/2012 01:33 PM, Erik P. Olsen wrote:
Well, since it makes bacula run, it IS a solution allthough I admit it IS bad.
No it isn't. It's a work-around that allows bacula to run while ignoring the central issue: you need to find out how to make bacula run correctly while running as user bacula. If the program itself is owned by that user, you may be able to get things going by using the suid bit. It's a tad weird, I know, and I'm not sure it's a Good Idea. However, if user bacula only has normal privileges, it's *probably* safe.
Turned out to be my fault (of course). Had mistyped a path to a log file so it would only run as root.
Am 01.07.2012 06:12, schrieb Erik P. Olsen:
On 30/06/12 22:43, Joe Zeff wrote:
On 06/30/2012 01:33 PM, Erik P. Olsen wrote:
Well, since it makes bacula run, it IS a solution allthough I admit it IS bad.
No it isn't. It's a work-around that allows bacula to run while ignoring the central issue: you need to find out how to make bacula run correctly while running as user bacula. If the program itself is owned by that user, you may be able to get things going by using the suid bit. It's a tad weird, I know, and I'm not sure it's a Good Idea. However, if user bacula only has normal privileges, it's *probably* safe.
Turned out to be my fault (of course). Had mistyped a path to a log file so it would only run as root.
and that was meant with "no it is not a solution" run as root :-)
-
Bill Shirley -
Erik P. Olsen -
Joe Zeff -
Reindl Harald