Red Hat Bugzilla – Bug 784868
service bacula-fd does not support chkconfig; cannot be enabled
Last modified: 2012-01-26 11:56:14 EST
Description of problem:
Puppet is having a hard time managing the baclua-fd service suddenly after it had been stable for a long time. It looks like service definition file is written for systemd, yet placed in the traditional SysVinit location:
# systemctl enable bacula-fd.service
bacula-fd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig bacula-fd on
service bacula-fd does not support chkconfig
# rpm -ql bacula-client | egrep 'systemd|init'
# cat /etc/rc.d/init.d/bacula-fd
Description=Bacula-FileDaemon, a Backup-client
ExecStart=/usr/sbin/bacula-fd -f $OPTS -c $CONFIG -u $FD_USER -g $FD_GROUP
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade to latest version of bacula-client.
2. Attempt to enable service using chkconfig or systemd.
Both 'systemctl enable bacula-fd.service' and 'chkconfig bacula-fd enable' fail to enable the service, with each complaining that they don't support it.
One or the other should work.
Please disregard. I had a problem with the yum meta-data on this machine which prevented the update. I've since found #784471 which alerted me to the fact that I had an older version in place. Works now!
*** This bug has been marked as a duplicate of bug 784471 ***
Thanks, yes, is fixed in 5.0.3-22.fc16.
One question, do you had to run ldconfig on applying the update?
(In reply to comment #2)
> Thanks, yes, is fixed in 5.0.3-22.fc16.
Yup, I can confirm that.
> One question, do you had to run ldconfig on applying the update?
Nothing of the sort. You're question had me wondering though since I never bounced the service, it was still/already running. So just now, I did stop/start the service to verify. It worked just fine.
Thanks, please see this thread also for additional information in the ongoing issues in the package:
Thanks for the heads up in that area, although I think I'm pretty safe in that area for now. Our director installation got upgraded from bacula-2 to bacula-5 by a cohort, to whom I had handed off all backup responsibilities. He's since left the company, so it's back in my lap now. I don't recall the exact reasons anymore, but he went with the upstream packages for the director and storage daemons. So in essence we're not even tracking Fedora's updates on the director.
Still, I appreciate your undertaking of what appears to be a gigantic task and making it "right". Someday I'm sure I'll be rebuilding that box and it'll be good to get back to tracking Fedora fully there and having this all sorted out.
Now if I only had the time to get my home systems off bacula2! :-) Many thanks to whomever made the call to provide the backwards compatibility packages.