Description of problem: bacuala's daemons don't start because it requires syslog which we don't provide anymore in mga4 Version-Release number of selected component (if applicable): 5.2.13 How reproducible: Every time Steps to Reproduce: 1. systemctl restart bacula-dir.service (or bacula-sf.service or bacula-fd.service) 2. I get a failed message because target-syslog doesn't exist (or similar) 3. Reproducible: Steps to Reproduce:
Status: NEW => ASSIGNED
Priority: Normal => HighAssignee: bugsquad => thomas
What do you mean we don't provide it anymore? The rsyslog package is no longer installed by default in new installs, but it is still available. If bacula (or one of its subpackage) needs it, it should require "syslog-daemon".
I can't see Bacula needing syslog. I think, it's just a leftover from earlier mga's. Why should we go back and install the syslog daemon when we moved to the journal bacula BTW bacula uses it's own log file. I put the fix into updates-testing and I have been running the updated bacula on my own server for about a week now.I haven't seen any errors and I have restored a couple of files without any glitches.
I have now been using bacula for about a month for daily backups and restored a couple of files as well. This fix is now ready to be tested. The following packages are in updates testing: bacula-5.2.13-3.3.mga4.src.rpm lib64bacula5-5.2.13-3.3.mga4.x86_64.rpm bacula-common-5.2.13-3.3.mga4.x86_64.rpm bacula-dir-common-5.2.13-3.3.mga4.x86_64.rpm bacula-dir-mysql-5.2.13-3.3.mga4.x86_64.rpm bacula-dir-pgsql-5.2.13-3.3.mga4.x86_64.rpm bacula-dir-sqlite3-5.2.13-3.3.mga4.x86_64.rpm bacula-console-5.2.13-3.3.mga4.x86_64.rpm bacula-bat-5.2.13-3.3.mga4.x86_64.rpm bacula-fd-5.2.13-3.3.mga4.x86_64.rpm bacula-sd-5.2.13-3.3.mga4.x86_64.rpm bacula-gui-bimagemgr-5.2.13-3.3.mga4.x86_64.rpm bacula-gui-brestore-5.2.13-3.3.mga4.x86_64.rpm bacula-tray-monitor-5.2.13-3.3.mga4.x86_64.rpm lib64baccats-mysql5-5.2.13-3.3.mga4.x86_64.rpm lib64baccats-postgresql5-5.2.13-3.3.mga4.x86_64.rpm lib64baccats-sqlite3_5-5.2.13-3.3.mga4.x86_64.rpm bacula-debuginfo-5.2.13-3.3.mga4.x86_64.rpm and i586 versions I can provide some guidance on how to configure bacula for testing (I am using mariadb (mysql) as database) I have not used the bacula-gui-xxx packages. bacula-bat provides a nice gui too. Assigning it now to QA
CC: (none) => thomasAssignee: thomas => qa-bugs
I don't see an advisory here. What did you change in the updated version?
Summary: bacuala's daemons don't start because it requires syslog which we don't provide anymore => bacula's daemons don't start because it requires syslog which we don't provide anymore
Advisory: I removed StandardOutput=syslog in service files otherwise the daemon will not start. We are not using syslog anymore I added the logdir as %{_logdir}/bacula to enable bacula to write into it. I did some cleanup such as removed init files (we are using systemd)
There are detailed configuration instructions here: http://lucasmanual.com/mywiki/Bacula#Configure_Bacula
CC: (none) => remiWhiteboard: (none) => has_procedure
hi, Test on Mageia 4 x86_64 : http://pastebin.com/wvXzbtYh Probably fail start, please look pastbin Thank you
CC: (none) => aranud
Trying MGA4 x64 with MariaDB. Following very helpful installion info given in Comment 6, "If the you don't have database created use the script supplied to install it" yields: $ mysql -u bacula -p < /usr/share/bacula-director/make_mysql_tables bash: /usr/share/bacula-director/make_mysql_tables: No such file or directory To advance? TIA
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #8) > Trying MGA4 x64 with MariaDB. > Following very helpful installion info given in Comment 6, "If the you don't > have database created use the script supplied to install it" yields: > $ mysql -u bacula -p < /usr/share/bacula-director/make_mysql_tables > bash: /usr/share/bacula-director/make_mysql_tables: No such file or directory > To advance? TIA You can search for it with urpmf: $ urpmf make_mysql_tables bacula-dir:/usr/libexec/bacula/make_mysql_tables
(In reply to Rémi Verschelde from comment #9) Thanks for rapid reply. > You can search for it with urpmf: > $ urpmf make_mysql_tables > bacula-dir:/usr/libexec/bacula/make_mysql_tables $ urpmf make_mysql_tables bacula-dir-mysql:/usr/lib64/bacula/make_mysql_tables Trying # mysql -u bacula -p < /usr/lib64/bacula/make_mysql_tables asked for a passsword for user bascula which I have not [yet] created. Need to research that...
(In reply to Lewis Smith from comment #8) > Trying MGA4 x64 with MariaDB. > Following very helpful installion info given in Comment 6, "If the you don't > have database created use the script supplied to install it" yields: > $ mysql -u bacula -p < /usr/share/bacula-director/make_mysql_tables > bash: /usr/share/bacula-director/make_mysql_tables: No such file or directory > To advance? TIA When you installed bacula-dir-common, it tried to run a script to create and install the database, but failed if your database uses a password. After installation of the package, run the script manually with the option -p and use your mysql root password The scripts need to be executed in the correct order Create database # systemctl enable mysqld.service # systemctl start mysqld.service # /usr/lib64/bacula/create_bacula_database mysql # /usr/lib64/bacula/make_bacula_tables mysql # /usr/lib64/bacula/grant_bacula_privileges mysql
Tried the following in vain:- $ mysql -p < /usr/lib64/bacula/make_mysql_tables Enter password: [reply with mariaDB root password] ERROR 1064 (42000) at line 9: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'bindir=/usr/bin PATH="$bindir:$PATH" db_name=${db_name:-bacula} if mysql -D ${d' at line 1 # mysql -p < /usr/lib64/bacula/create_bacula_database mysql Enter password: [reply with mariaDB root password] ERROR 1064 (42000) at line 6: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'bindir=/usr/bin db_name=bacula if $bindir/mysql $* -f <<END-OF-DATA CREATE DATA' at line 1 Appreciate your support - evidently needed!
Thanks to Thomas Comment 11. Advancing. For the benefit of others, to clarify what has preceded... It seems that you have to create the MariaDB/MySQL user in advance. And to do this, you first have to create a database for that user. So I did:- $ mysql -u root -p Enter password: MariaDB [(none)]> CREATE DATABASE bacula ; MariaDB [(none)]> GRANT ALL ON bacula.* TO 'bacula'@'localhost' IDENTIFIED BY 'bacula' ; (note the necessary quotes around username & hostname). The script/usr/share/bacula-director/make_mysql_tables cited in Comment 8 *does not exist*. Use those from Comment 11 instead, *with* the -p (for the database root user) thus:- # /usr/lib64/bacula/create_bacula_database mysql -p Enter password: ERROR 1007 (HY000) at line 1: Can't create database 'bacula'; database exists Creation of bacula database succeeded. # /usr/lib64/bacula/make_bacula_tables mysql -p Enter password: Creation of Bacula MySQL tables succeeded. # /usr/lib64/bacula/grant_bacula_privileges mysql -p Enter password: Host User Password Select_priv Insert_priv Update_priv ... Privileges for user bacula granted on database bacula. So I can proceed further.
Problems again. Following the first post-install step 'Director' in the link given in Comment 6: http://lucasmanual.com/mywiki/Bacula#Configure_Bacula with all given changes to 'bacula-dir.conf' done, I cannot start bacula-director - shown bacula-dir in MCC Services & Daemons display. It is shown as 'stopped' and its Start button has no effect. [bacula-fd & bacula-sd *are* both running]. The given start command fails: # /etc/init.d/bacula-director start bash: /etc/init.d/bacula-director: No such file or directory Trying: # /etc/init.d/bacula-dir start Starting bacula-dir (via systemctl): Failed to issue method call: Unit syslog.target failed to load: No such file or directory. Also as suggested: $ cat /var/log/bacula/log cat: /var/log/bacula/log: No such file or directory Once again, Help please!
Created attachment 5346 [details] installation How-To for testing
(In reply to Lewis Smith from comment #14) > Problems again. > Following the first post-install step 'Director' in the link given in > Comment 6: > http://lucasmanual.com/mywiki/Bacula#Configure_Bacula > with all given changes to 'bacula-dir.conf' done, I cannot start > bacula-director - shown bacula-dir in MCC Services & Daemons display. It is > shown as 'stopped' and its Start button has no effect. [bacula-fd & > bacula-sd *are* both running]. The given start command fails: > # /etc/init.d/bacula-director start > bash: /etc/init.d/bacula-director: No such file or directory > Trying: > # /etc/init.d/bacula-dir start > Starting bacula-dir (via systemctl): Failed to issue method call: Unit > syslog.target failed to load: No such file or directory. > > Also as suggested: > $ cat /var/log/bacula/log > cat: /var/log/bacula/log: No such file or directory > > Once again, Help please! We use Systemd! I just did a virgin installation on a mga4 VM and put a mga specific how-to as an attachment. I hope this will help.
Thomas re Comment 16 Thanks very much for this HowTo. Confess I did not get the context of the part beween asterisks "using mcc from a root shell", nor where & in reponse to what this output happens. Not important here because I had already run the three scripts as you specify subsequently, all OK as per my Comment 13. But bacula-dir is giving me the same fault as before (Commment 14, where the obsolete /etc/init.d/bacula-dir start was redirected Starting bacula-dir (via systemctl)): # systemctl start bacula-dir Failed to issue method call: Unit syslog.target failed to load: No such file or directory. I do not think I can advance without cracking this one.
This looks like you haven't done the upgrade and your testing the version for which the bug was filed. What is your output [root@vbox ~]# rpm -qa |grep bacula You should have: bacula-fd-5.2.13-3.3.mga4 bacula-bat-5.2.13-3.3.mga4 lib64bacula5-5.2.13-3.3.mga4 bacula-sd-5.2.13-3.3.mga4 bacula-dir-common-5.2.13-3.3.mga4 bacula-common-5.2.13-3.3.mga4 bacula-console-5.2.13-3.3.mga4 bacula-dir-mysql-5.2.13-3.3.mga4 and this [root@vbox ~]# systemctl -l status bacula-dir bacula-dir.service - Bacula-Director, the Backup-server Loaded: loaded (/usr/lib/systemd/system/bacula-dir.service; enabled) Active: active (running) since Fri 2014-08-15 15:10:36 MST; 23h ago Docs: man:bacula-dir(8) Process: 10192 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 10198 (bacula-dir) CGroup: /system.slice/bacula-dir.service ââ10198 /usr/sbin/bacula-dir -f -c /etc/bacula/bacula-dir.conf -u bacula -g bacula Aug 15 15:10:36 vbox.btspuhler.com systemd[1]: Started Bacula-Director, the Backup-server. [root@vbox ~]#
Thomas Thanks for your help & patience. > This looks like you haven't done the upgrade and your testing the version for which the bug was filed. Correct. It is normal to install the public version of anything & try it *before* updating it from Testing, both to ensure that the update itself goes without hitches, & to spot new problems/regressions. Apologies if this was not appropriate in this case. So updated everything from Updates Testing to: bacula-bat-5.2.13-3.3.mga4 bacula-common-5.2.13-3.3.mga4 bacula-console-5.2.13-3.3.mga4 bacula-dir-common-5.2.13-3.3.mga4 bacula-dir-mysql-5.2.13-3.3.mga4 bacula-fd-5.2.13-3.3.mga4 bacula-gui-bimagemgr-5.2.13-3.3.mga4 bacula-gui-brestore-5.2.13-3.3.mga4 bacula-sd-5.2.13-3.3.mga4 bacula-tray-monitor-5.2.13-3.3.mga4 lib64bacula5-5.2.13-3.3.mga4 & tried again: # systemctl restart bacula-dir which this time gave no complaint. But: # systemctl -l status bacula-dir was not so successful: bacula-dir.service - Bacula-Director, the Backup-server Loaded: loaded (/usr/lib/systemd/system/bacula-dir.service; enabled) Active: failed (Result: start-limit) since Sul 2014-08-17 21:05:09 CEST; 7s ago Docs: man:bacula-dir(8) Process: 17155 ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u $DIR_USER -g $DIR_GROUP (code=exited, status=127) Process: 17152 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 17155 (code=exited, status=127) Aws 17 21:05:09 localhost systemd[1]: Started Bacula-Director, the Backup-server. Aws 17 21:05:09 localhost systemd[1]: bacula-dir.service: main process exited, code=exited, status=127/n/a Aws 17 21:05:09 localhost systemd[1]: Unit bacula-dir.service entered failed state. Aws 17 21:05:09 localhost bacula-dir[17155]: /usr/sbin/bacula-dir: error while loading shared libraries: libbaccats-5.2.13.so: cannot open shared object file: No such file or directory Aws 17 21:05:09 localhost systemd[1]: bacula-dir.service holdoff time over, scheduling restart. Aws 17 21:05:09 localhost systemd[1]: Stopping Bacula-Director, the Backup-server... Aws 17 21:05:09 localhost systemd[1]: Starting Bacula-Director, the Backup-server... Aws 17 21:05:09 localhost systemd[1]: bacula-dir.service start request repeated too quickly, refusing to start. Aws 17 21:05:09 localhost systemd[1]: Failed to start Bacula-Director, the Backup-server. Aws 17 21:05:09 localhost systemd[1]: Unit bacula-dir.service entered failed state. I hope you can deduce something from this lot. TIA
(In reply to Lewis Smith from comment #19) > Thomas > > Thanks for your help & patience. > > This looks like you haven't done the upgrade and your testing the version for which the bug was filed. > Correct. It is normal to install the public version of anything & try it > *before* updating it from Testing, both to ensure that the update itself > goes without hitches, & to spot new problems/regressions. Apologies if this > was not appropriate in this case. I think, it was appropriate, but you complained about things not working that were the reason for the bug report (in the title of the report) > So updated everything from Updates Testing to: > bacula-bat-5.2.13-3.3.mga4 > bacula-common-5.2.13-3.3.mga4 > bacula-console-5.2.13-3.3.mga4 > bacula-dir-common-5.2.13-3.3.mga4 > bacula-dir-mysql-5.2.13-3.3.mga4 > bacula-fd-5.2.13-3.3.mga4 > bacula-gui-bimagemgr-5.2.13-3.3.mga4 > bacula-gui-brestore-5.2.13-3.3.mga4 > bacula-sd-5.2.13-3.3.mga4 > bacula-tray-monitor-5.2.13-3.3.mga4 > lib64bacula5-5.2.13-3.3.mga4 > & tried again: > # systemctl restart bacula-dir > which this time gave no complaint. But: > # systemctl -l status bacula-dir was not so successful: > > bacula-dir.service - Bacula-Director, the Backup-server > Loaded: loaded (/usr/lib/systemd/system/bacula-dir.service; enabled) > Active: failed (Result: start-limit) since Sul 2014-08-17 21:05:09 CEST; > 7s ago > Docs: man:bacula-dir(8) > Process: 17155 ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u > $DIR_USER -g $DIR_GROUP (code=exited, status=127) > Process: 17152 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG > (code=exited, status=0/SUCCESS) > Main PID: 17155 (code=exited, status=127) > > Aws 17 21:05:09 localhost systemd[1]: Started Bacula-Director, the > Backup-server. > Aws 17 21:05:09 localhost systemd[1]: bacula-dir.service: main process > exited, code=exited, status=127/n/a > Aws 17 21:05:09 localhost systemd[1]: Unit bacula-dir.service entered failed > state. > Aws 17 21:05:09 localhost bacula-dir[17155]: /usr/sbin/bacula-dir: error > while loading shared libraries: libbaccats-5.2.13.so: cannot open shared > object file: No such file or directory > Aws 17 21:05:09 localhost systemd[1]: bacula-dir.service holdoff time over, > scheduling restart. > Aws 17 21:05:09 localhost systemd[1]: Stopping Bacula-Director, the > Backup-server... > Aws 17 21:05:09 localhost systemd[1]: Starting Bacula-Director, the > Backup-server... > Aws 17 21:05:09 localhost systemd[1]: bacula-dir.service start request > repeated too quickly, refusing to start. > Aws 17 21:05:09 localhost systemd[1]: Failed to start Bacula-Director, the > Backup-server. > Aws 17 21:05:09 localhost systemd[1]: Unit bacula-dir.service entered failed > state. > > I hope you can deduce something from this lot. TIA Did you upgrade everything of bacula? I don't see lib64baccats-mysql5-5.2.13-3.3.mga4 When you upgrade this, it should run a script that make the link.
(In reply to Thomas Spuhler from comment #20) > Did you upgrade everything of bacula? I don't see > lib64baccats-mysql5-5.2.13-3.3.mga4 > When you upgrade this, it should run a script that make the link. Yes, I *did* upgrade everything. My list in Comment 19 was erroneously pkg filtered with 'bacula'; but doing:- $ rpm -qa | grep lib64baccats-mysql5 lib64baccats-mysql5-5.2.13-3.3.mga4 shows it *is* in place. Over to you again... If you can suggest some manipulation to "make the link", please do. Or perhaps I should downgrade & try again - but please tell me how; I think there is a Mageia rpm command to do it.
I did some screw up of the link so bacula-dir wouldn't start anymore and then did urpmi --replacepkgs lib64baccats-mysql5 and I got the link back and bacula-dir did start again. I think this script should work: /usr/sbin/update-alternatives --install /usr/lib64/libbaccats-5.2.13.so libbaccats-5.2.13.so /usr/lib64/libbaccats-mysql.so 2
(In reply to Thomas Spuhler from comment #22) > # urpmi --replacepkgs lib64baccats-mysql5 [using normal, *not* Testing repos] yielded: "lib64baccats-mysql5-5.2.13-3.mga4.x86_64 is in the urpmi DB but not installed." > and I got the link back and bacula-dir did start again. Same here; but so did it in my Comment 19. > I think this script should work: > # /usr/sbin/update-alternatives --install /usr/lib64/libbaccats-5.2.13.so > libbaccats-5.2.13.so /usr/lib64/libbaccats-mysql.so 2 I did this (all on one line), no output. # systemctl restart bacula-dir # systemctl -l status bacula-dir gave the same bad output as in Comment 19. I think I shall UNinstall bacula & start again from scratch - but re-installing from Updates Testing..
Did that. Have the 9 5.2.13-3.3.mga4 pkgs defined in Comments 18 & 21. Re-running the 3 scripts defined in Comment 11 + the -p option (for MariaDB root password), the first two reported (reasonably) that the DB and all tables were already defined, but Creation of bacula database succeeded. Creation of Bacula MySQL tables succeeded. & Privileges for user bacula granted on database bacula. # systemctl start bacula-dir [OK] # systemctl -l status bacula-dir STILL gives the duff output shown in Comment 19 (correct being in Comment 18). From the HowTo ex Comment 15: # systemctl start bacula-dir [OK] # systemctl start bacula-sd [OK] # systemctl start bacula-fd [OK] # bconsole Connecting to Director localhost:9101 # Not so good.Trying: # bat brought up the window, which displayed the same 'Connecting' message, then nothing; or an error box:. "bat: ABORTING due to ERROR in console/console.cpp:157 Failed to connect to localhost-dir for populateLists." Does this help?
A confession (but it changes nothing): up to now I had only edited as per the link given in Comment 6: bacula-dir.conf but only now I did the other 3 (all Passwords): bacula-sd.conf bacula-fd.conf bconsole.conf After [Re]Starting the 3 bacula services, all of: bconsole, systemctl -l status bacula-dir, bat gave the same unsatisfactory results as above in Comment 24.
(In reply to Lewis Smith from comment #25) > A confession (but it changes nothing): up to now I had only edited as per > the link given in Comment 6: > bacula-dir.conf > but only now I did the other 3 (all Passwords): > bacula-sd.conf > bacula-fd.conf > bconsole.conf > After [Re]Starting the 3 bacula services, all of: > bconsole, systemctl -l status bacula-dir, bat > gave the same unsatisfactory results as above in Comment 24. Sorry, but I am busy running against an cauldron upgrade deadline. I am a little concerned about your "but only now I did the other 3 (all Passwords)" statement above. did you change the password in those 3 conf files? You shouldn't. Leave the passwords alone. They were randomly created during installation. another concern is your statement "bat: ABORTING due to ERROR in console/console.cpp:157" Does the command bconsole yield anything?
Any progress on this?
It's next on my list Thomas.
No problem, just wanted to make certain, it's not forgotten.
Thomas This is the top of my list, since ages; I have cleared the decks to re-try it from scratch. I have simply been too occupied to do any bug testing this past week.
At last retrying this MGA4 real hardware after having cleared out everything 'bacula' I could find. I re-installed with urpmi from normal repos all the pkgs listed in Comment 3 *except* the 2-each PostgreSQL & SQlite ones; bacula-debuginfo did not exist. One of the early ones gave the output between ********* cited in the installation HowTo referenced from Comment 15. The three scripts referenced in the HowTo: # /usr/lib64/bacula/create_bacula_database -p # /usr/lib64/bacula/make_bacula_tables -p # /usr/lib64/bacula/grant_bacula_privileges -p with MariaDB and *no* bacula database or user pre-defined, gave output as per the HowTo. Trying to [re]start the three bacula daemons yielded "Failed to issue method call: Unit syslog.target failed to load: No such file or directory." but using MCC Services showed that all three were running OK. # bconsole yielded correctly: Connecting to Director localhost:9101 1000 OK: localhost-dir Version: 5.2.13 (19 February 2013) Enter a period to cancel a command. and using most of the commands given in http://www.lucasmanual.com/mywiki/Bacula Manage bacula - bconsole - using bacula gave sensible output. I edited /etc/bacula/bacula-dir.conf as per the HowTo, but *not* as per the lucasmanual page. Tried # bat and the same GUI program from the menu and they both seemed to work (though giving less info than bconsole). bat gave 2 GConf-WARNINGs --------------------------------------- Then updated everything from Updates Testing, which asked for confirmation of trivial changes to the 3 config files (which I accepted, use rpmnew). # systemctl restart bacula-dir # systemctl restart bacula-sd # systemctl restart bacula-fd all worked without complaint this time. HOWEVER, the GUI, whether from menu or command, stuck on "Connecting to Director localhost:9101" and seized up eventually with a message box "bat: ABORTING due to ERROR in console/console.cpp:157 Failed to connect to localhost-dir for populateLists." terminating in Segmentation fault. Both the long GConf-WARNINGs were still output previously. # bconsole Connecting to Director localhost:9101 got no further. For me this is mostly reversion. Am I alone?
trivial changes to the 3 config files (which I accepted, use rpmnew) Since you accepted the "use rpmnew" you need to configure them again. I think you should use the old ones. The new ones will probably have new passwords and reverted the configurations you made.
Having another go with a fresh Mageia4 x64 install, fully updated. Installed from issued repos using MCC: bacula-bat-5.2.13-3.mga4 bacula-dir-common-5.2.13-3.mga4 bacula-fd-5.2.13-3.mga4 bacula-console-5.2.13-3.mga4 lib64bacula5-5.2.13-3.mga4 bacula-sd-5.2.13-3.mga4 bacula-common-5.2.13-3.mga4 bacula-dir-mysql-5.2.13-3.mga4 lib64baccats-mysql5-5.2.13-3.mga4 and ran the 3 scripts in the HowTo, output as it should be. The 3 'systemctl start bacula..' all failed "Failed to issue method call: Unit syslog.target failed to load: No such file or directory" as per my Comment 31, but *this* time MCC System-Services showed them as STOPPED, and trying to start them *did not work*. *Neither did bconsole* which stopped at "Connecting to Director localhost:9101". Why this difference? I did the small bacula-dir.conf edit suggested in the HowTo. Am going to re-boot, re-try the original bacula, then do the update and try that. To follow.
Good: after re-booting, the bacula daemons *were* running, and both bconsole (commands from the Lucas page) and bat GUI gave sensible output. From Updates Testing, updated via MCC to: - bacula-bat-5.2.13-3.3.mga4.x86_64 - bacula-common-5.2.13-3.3.mga4.x86_64 - bacula-console-5.2.13-3.3.mga4.x86_64 - bacula-dir-common-5.2.13-3.3.mga4.x86_64 - bacula-dir-mysql-5.2.13-3.3.mga4.x86_64 - bacula-fd-5.2.13-3.3.mga4.x86_64 - bacula-sd-5.2.13-3.3.mga4.x86_64 - lib64baccats-mysql5-5.2.13-3.3.mga4.x86_64 this time *not* accepting the 3 rpmnew config files. # systemctl restart bacula-dir # systemctl restart bacula-sd # systemctl restart bacula-fd But the unsatisfactory result is the same as my Comment 31: # bconsole Connecting to Director localhost:9101 # Trying the GUI from menu... "bat: ABORTING due to ERROR in console/console.cpp:157 Failed to connect to localhost-dir for populateLists" Same via the following command: # bat (process:6721): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (bat:6721): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed (bat:6721): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Segmentation fault I shall re-boot, and only add to this bug if things then *work*. If they still do not work, there is nothing more I can do without specific advice.
I add this in case it helps... After re-booting, MCC System-Services showed bacula-dir STOPPED, and clicking to start it had no effect. The other two daemons were running OK. Trying from console: # systemctl start bacula-dir [seems to work, but MCC showed it STOPPED] # bconsole Connecting to Director localhost:9101 # Stalemate.
Mageia4 x64. Last ditch attempt. For others who follow, to purge your system of bacula (using MariaDB/MySQL), you need to: - remove the 9 pkgs cited in Comment 33. - remove /etc/bacula - remove /var/spool/bacula - remove bacula User and Database from MariaDB. Having done that, I installed bacula 5.2.13-3.mga4 x64, the 9 pkgs, *directly from Updates Testing*. Ran the 3 scripts in the HowTo, output as expected. Did the trivial bacula-dir.conf edit suggested in the HowTo. Started the 3 daemons, which did so without error. bconsole & bat GUI then *worked*. Recap: bacula installed as in the HowTo from Release works except for the errors output from systemctl start bacula-xxx. (It may need a reboot to get bacula-dir running). After the update, the systemctl bacula-xxx commands work, but bacula itself does not. This behaviour is the same whether the original 3 config files are preserved during the update, or the changed ones accepted. Installed directly from the Update, it works all round. Which suggests there is a problem with the UPDATE itself, possibly related to bacula-dir.conf . Comments 33 & 34 re systemctl start bacula-xxx show I think that the root problem addressed by this update *is* corrected.
Testing on Mageia4-64 real h/w Before : ------ Installing : - bacula-bat-5.2.13-3.mga4.x86_64 - bacula-common-5.2.13-3.mga4.x86_64 - bacula-console-5.2.13-3.mga4.x86_64 - bacula-dir-common-5.2.13-3.mga4.x86_64 - bacula-dir-mysql-5.2.13-3.mga4.x86_64 - bacula-fd-5.2.13-3.mga4.x86_64 - bacula-sd-5.2.13-3.mga4.x86_64 - lib64baccats-mysql5-5.2.13-3.mga4.x86_64 - lib64bacula5-5.2.13-3.mga4.x86_64 - lib64mariadb-devel-5.5.39-1.mga4.x86_64 - mtx-1.3.12-5.mga4.x86_64 - smartmontools-6.2-2.mga4.x86_64 # /usr/lib64/bacula/create_bacula_database -p Enter password: Creation of bacula database succeeded. # /usr/lib64/bacula/make_bacula_tables -p Enter password: Creation of Bacula MySQL tables succeeded. # /usr/lib64/bacula/grant_bacula_privileges -p Enter password: Privileges for user bacula granted on database bacula. reboot # bconsole Connecting to Director localhost:9101 1000 OK: localhost-dir Version: 5.2.13 (19 February 2013) Enter a period to cancel a command. Started Gestionnaire de Bacula (QT4) It showed that bacula complaine about labels not set. so : # bconsole *label Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" Automatically selected Storage: File Enter new Volume name: zitoun Defined Pools: 1: Default 2: File 3: Scratch Select the Pool (1-3): 1 Connecting to Storage daemon File at localhost:9103 ... Sending label command for Volume "zitoun" Slot 0 ... 3000 OK label. VolBytes=200 DVD=0 Volume="zitoun" Device="FileStorage" (/var/spool/bacula) Catalog record for Volume "zitoun", Slot 0 successfully created. Requesting to mount FileStorage ... 3906 File device ""FileStorage" (/var/spool/bacula)" is always mounted. Returned to Bacula QT4 and ran two jobs (already set in installation) # bconsole *status dir localhost-dir Version: 5.2.13 (19 February 2013) x86_64-mageia-linux-gnu mageia (Cauldron) Daemon started 21-Oct-14 01:07. Jobs: run=2, running=0 mode=0,0 Heap: heap=393,216 smbytes=113,811 max_bytes=135,461 bufs=290 max_bufs=312 (...) Terminated Jobs: JobId Level Files Bytes Status Finished Name ==================================================================== 3 Full 1 28.37 K OK 21-Oct-14 01:08 BackupCatalog 4 Full 588 79.16 M OK 21-Oct-14 01:09 BackupClient1 ... which confirmed that the two backups had been done. Stopped and disabled all bacula services (bacula-dir, bacula-sd, bacula-fd) Dropped bacula database After : ----- Installed update-testing packages = - bacula-bat-5.2.13-3.3.mga4.x86_64 - bacula-common-5.2.13-3.3.mga4.x86_64 - bacula-console-5.2.13-3.3.mga4.x86_64 - bacula-dir-common-5.2.13-3.3.mga4.x86_64 - bacula-dir-mysql-5.2.13-3.3.mga4.x86_64 - bacula-fd-5.2.13-3.3.mga4.x86_64 - bacula-sd-5.2.13-3.3.mga4.x86_64 - lib64baccats-mysql5-5.2.13-3.3.mga4.x86_64 - lib64bacula5-5.2.13-3.3.mga4.x86_64 Started bacula-dir, bacula-fd, bacula-sd Unable to start bacula-dir, even after reboot. # systemctl -l status bacula-dir bacula-dir.service - Bacula-Director, the Backup-server Loaded: loaded (/usr/lib/systemd/system/bacula-dir.service; enabled) Active: failed (Result: start-limit) since mar. 2014-10-21 01:35:45 CEST; 9min ago Docs: man:bacula-dir(8) Process: 8819 ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u $DIR_USER -g $DIR_GROUP (code=exited, status=127) Process: 8815 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS) Main PID: 8819 (code=exited, status=127) oct. 21 01:35:45 mageialan bacula-dir[8819]: /usr/sbin/bacula-dir: error while loading shared libraries: libbaccats-5.2.13.so: cannot open shared object file: No such file or directory (...) As found in Comment 22, though I had installed lib64baccats-mysql5-5.2.13-3.3.mga4.x86_64, I issued : # urpmi --replacepkgs lib64baccats-mysql5 That time, bacula-dir service could start. Once more, ran two jobs already configured. # bconsole *status dir localhost-dir Version: 5.2.13 (19 February 2013) x86_64-mageia-linux-gnu mageia (Official) Daemon started 21-Oct-14 01:48. Jobs: run=2, running=0 mode=0,0 Heap: heap=393,216 smbytes=99,840 max_bytes=136,728 bufs=264 max_bufs=314 (...) Terminated Jobs: JobId Level Files Bytes Status Finished Name ==================================================================== 3 Full 1 28.37 K OK 21-Oct-14 01:08 BackupCatalog 4 Full 588 79.16 M OK 21-Oct-14 01:09 BackupClient1 1 Full 1 26.49 K OK 21-Oct-14 01:49 BackupCatalog 2 Full 591 79.18 M OK 21-Oct-14 01:49 BackupClient1 which showed the jobs had successfully been fulfilled. The update runs fine as long as you replace manually lib64baccats-mysql5. So I would conclude it is not so fine.
CC: (none) => olchal
did you run the script from comment 26? You need to make a link when you install with urpmi from normal repos, either manually or I think this script should work: /usr/sbin/update-alternatives --install /usr/lib64/libbaccats-5.2.13.so libbaccats-5.2.13.so /usr/lib64/libbaccats-mysql.so 2 If you install from the upgrade-testing, the link is automatically added as far as I remember.
Sorry Thomas, I didn't read comment properly so didn't make the link. Retraced same procedure as in comment 37 on Mageia 4x32 this time With current packages, no issues. With update-testing packages : - bacula-bat-5.2.13-3.3.mga4.i586 - bacula-common-5.2.13-3.3.mga4.i586 - bacula-console-5.2.13-3.3.mga4.i586 - bacula-dir-common-5.2.13-3.3.mga4.i586 - bacula-dir-mysql-5.2.13-3.3.mga4.i586 - bacula-fd-5.2.13-3.3.mga4.i586 - bacula-sd-5.2.13-3.3.mga4.i586 - libbaccats-mysql5-5.2.13-3.3.mga4.i586 - libbacula5-5.2.13-3.3.mga4.i586 Ran Thomas' script : # /usr/sbin/update-alternatives --install /usr/lib/libbaccats-5.2.13.so libbaccats-5.2.13.so /usr/lib/libbaccats-mysql.so 2 All went well, bacula-dir, bacula-sd, bacula-fd running without problems, could complete 2 jobs, read messages in # bconsole and read status status dir
Thanks for re-testing.
Is it a MGA4-32-OK Olivier?
First test (comment 37) was run on Mageia4-64. Secund test (comment 39) was run on Mageia4-32.
And do you validate those tests? If so, please push the corresponding tags in the whiteboard field: MGA4-32-OK and MGA4-64-OK. Then you can validate the update by putting the validated_update keyword in the keywords field.
Wait a moment. Is this update viable if it needs the extra step in Comment 38 ? I am not clear at what point this needs to be done: - After installation from Normal repos, before the Update; or - After the Update. I am poised to start again from scratch (if only to second Olivier's tests) on x64. And what is one supposed to do about the Update proposed trivial changes to the 3 config files? They seemed innocent enough to me to accept, but Thomas suggested it was better to keep the original versions.
It's not uncommon for config files to change lewis. It shouldn't nuke your changes so should ask whether to save the new conf file as .rpmnew or use it. If that happens then it is packaged correctly. It is not valid to require users to set up an alternative using the alternatives system though as an extra step, that should be done in %post/%pre etc.
(In reply to Lewis Smith from comment #44) > Wait a moment. > Is this update viable if it needs the extra step in Comment 38 ? > I am not clear at what point this needs to be done: > - After installation from Normal repos, before the Update; > or > - After the Update. > I am poised to start again from scratch (if only to second Olivier's tests) > on x64. > > And what is one supposed to do about the Update proposed trivial changes to > the 3 config files? They seemed innocent enough to me to accept, but Thomas > suggested it was better to keep the original versions. <Is this update viable if it needs the extra step in Comment 38> This has nothing to do with the upgrade. It has to be done once and it's not a config file. Yes, do not change the config files. You have the option if you use the gui, do not change. If you use urpmi, they won't be changed anyway.
> <Is this update viable if it needs the extra step in Comment 38> > This has nothing to do with the upgrade. It has to be done once and it's not > a config file. I am far from sure. Comment 45 seems to support this view: > It is not valid to require users to set up an alternative using the > alternatives system though as an extra step, that should be done in > %post/%pre etc Bacula works (at least after a re-boot; the Comment 38 command made no difference) when installed as per your HowTo from current Core Release repo. It also works out-of-the-box if installed directly from Updates Testing (Comments 36 & 38). It does *not* immediately work (Comments 34 & 37) if *updated* from the former to the latter; it seems that it is *here* that you need to apply the Comment 38 command, which indeed results in it working again. Note: it made no difference whether the original or new config files were chosen. I have just re-verified this, which supports Comment 39. It just seems to me that the Comment 38 command should be an integral part of the update. Both myself & Olivier have shown the effectiveness of it after the update: - without it, bacula-dir does not start - applying it, bacula-dir does start. Sorry if I am mistaken. To Claire, Comment 45 > It's not uncommon for config files to change lewis. It shouldn't nuke your > changes so should ask whether to save the new conf file as .rpmnew or use it. > If that happens then it is packaged correctly. Yes, I know... This *is* packaged correctly, does as you say.
That's good Lewis, thanks. It sounds like we can validate then.
Well I wonder why the update-alternatives thing can't be made in a %post script, or at least document in a README.urpmi? If the update candidate breaks currently functioning setups, then it's a serious enough regression to try to handle it in the packaging. Unless I've overlooked (which is possible), it seems you did not state why it should not be done in a %post script Thomas?
My impression from Lewis's comment is that it is only required when updating from the current (broken) version. It should have been in that version rather than this one and that this one works OOTB. It would certainly be good to include a fix for this if doing so would not cause breakage in the new, working package. Thomas could maybe clarify.
Rereading comment 47 more thoroughly it does indeed sound like it is the update that breaks things. I'm trying to do too many things at once. So my comment 48 was premature.
(In reply to claire robinson from comment #51) > Rereading comment 47 more thoroughly it does indeed sound like it is the > update that breaks things. I'm trying to do too many things at once. So my > comment 48 was premature. I thought it was. Do indeed re-read Comment 47; and Comment 36 where I first suspected the problem: > Which suggests there is a problem with the UPDATE itself and Comment 37 where Olivier discovered his own solution: > The update runs fine as long as you replace manually lib64baccats-mysql5. > So I would conclude it is not so fine and Comment 39 where he confirms the effectiveness of the extra post-update step.
Sorry for being quiet this long. I did a lot of testing and it seems the %post script is not running when upgrading lib64baccats-mysql5. Of course, this makes sense since update-alternative is meant for the admin to change the settings. (/usr/sbin/update-alternatives --install /usr/lib64/libbaccats-5.2.13.so libbaccats-5.2.13.so /usr/lib64/libbaccats-mysql.so 2) There was a reason why the original mdv/mdk packager did it this way and I suggest to leave it as is. What we now need to do is provide the user with an advice to run this script after the upgrade. I will do this now. From what I can see everything else works as intended.
Thanks Lewis for being such persistent. I think we now have a good solution with providing a REAME.upgrade.urpmi. I submitted the packages as subrel 4 to updates_testing.
(In reply to Rémi Verschelde from comment #49) > Well I wonder why the update-alternatives thing can't be made in a %post > script, or at least document in a README.urpmi? If the update candidate > breaks currently functioning setups, then it's a serious enough regression > to try to handle it in the packaging. > > Unless I've overlooked (which is possible), it seems you did not state why > it should not be done in a %post script Thomas? Remy: %post script : it's there already and it does it when you install the package, but not when upgrading it as mentioned in comment 53. I stumped over that. When you read the update-alternatives manual, it all makes sense. update-alternatives is used so the administrator has to make the changes explicitly. The now added README.upgrades.urpmi addresses this.
No. update-alternatives is not an "administrator only" thing. We use it in several packages to set the defaults according to what is needed... if its an upgrade issue, you can use rpm version triggers to make it a "one-time change"
CC: (none) => tmb
Whiteboard: has_procedure => has_procedure feedback
Let's leave it as it is and use update-alternatives
What's happening with this update please?
Are we going to release this soon?
Was actually waiting on your feedback Thomas. Updates shouldn't require manual intervention, see comment 56.
Assigning back to Thomas. Please reassign to QA when ready.
Assignee: qa-bugs => thomasCC: (none) => qa-bugs
Sorry, I was too busy with cauldron and security bugs. Can we move this now? I am going to assign this back to QA. All what was wrong were misunderstandings. If you update from the mga4 release or you install fresh from updates there is no manual intervention required. For testing, just install: bacula-bat bacula-sd bacula-fd bacula-console bacula-dir-mysql It will pull in all required packages. start the mysqld (if not already done) and run the database creation scripts manually (if the database is secured with a password). If mariadb is installed w/o password and started, it's all done during the installtion process. reboot add in /etc/bacula/bacula-dir.conf at the end of the # File Pool definition LabelFormat = "Vol" Now try to start all deamons. bacula-dir.service will fail (the reason why thus bug was started.) now do the upgrade from updates_testing and then use as root "bat" (or bconsole) Do a backup with the current configuration. (it should complete in about 15 minutes or less)
Assignee: thomas => qa-bugs
Whiteboard: has_procedure feedback => has_procedure
Testing MGA4 x64 Re-started from a clean sheet: removed /etc/bacula, /var/spool/bacula, and all the 9 pkgs below. Removed from MariaDB the bacula DB, and both bacula users. Installed subsequently from normal repos: - bacula-bat-5.2.13-3.mga4.x86_64 - bacula-common-5.2.13-3.mga4.x86_64 - bacula-console-5.2.13-3.mga4.x86_64 - bacula-dir-common-5.2.13-3.mga4.x86_64 - bacula-dir-mysql-5.2.13-3.mga4.x86_64 - bacula-fd-5.2.13-3.mga4.x86_64 - bacula-sd-5.2.13-3.mga4.x86_64 - lib64baccats-mysql5-5.2.13-3.mga4.x86_64 - lib64bacula5-5.2.13-3.mga4.x86_64 Ran the 3 scripts in the HowTo [Comment 15]. Edited /etc/bacula/bacula-dir.conf: at the end of the # File Pool definition, add LabelFormat = "Vol" Doing # systemctl start bacula-dir | -sd | -fd yielded: "Failed to issue method call: Unit syslog.target failed to load: No such file or directory." - the bug in question. Reboot, the services start. Played with bconsole, & bat/QT4 graphical interface; all seems OK. No backup done (no idea how). Updated from Updates Testing repo the 9 pkgs (all -3.4.mga4). Refused .rpmnew configs. There is now an additional information window specifying exact post-update commands which need to be run according to the DB in question. You need to carefully save the one that matters! Executed the given command for MySQL (MariaDB) DB, re-started the services: # systemctl restart bacula-dir | -sd | -fd No errors. Playing with bconsole & bat/QT4 again seemed OK. No backup done. So all that has happened is to include the necessary extra post-update command - as information only, it is not done for you - as part of the update. But it works. OKing this at last.
Whiteboard: has_procedure => has_procedure MGA4-64-OK
Validating. Advisory compiled from bug comments as.. + Updated bacula packages remove the syslog requirement, which could prevent + it from starting if missing, and correct some packaging issues. Please push to 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: has_procedure MGA4-64-OK => has_procedure advisory MGA4-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0040.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED