Bug 3797

Created attachment 1254 [details]
/var/log/mysqld/mysqld.log snippet

(In reply to comment #1)
> Created attachment 1254 [details]
> /var/log/mysqld/mysqld.log snippet

Sorry, You may want to do an immediate  systemctl start mysqld.service 
should have been    systemctl stop mysqld.service

Hi, thanks for reporting this bug.
Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)

Keywords: (none) => Triaged
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=3710
Assignee: bugsquad => alien

could this be due to systemd? i couldn't reproduce before... (not using systemd)

(In reply to comment #4)
> could this be due to systemd? 

Since Release 2 default is systemd, I would say it is.

I'll recommend you install VirtualBox, create a guest with a clean install, apply updates and see how it goes. :)

looks fine to me... (with sysvinit)

i did:

[root@localhost mariadb-5.5.18]# /etc/init.d/mysqld start
Initializing the system database: 
Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
OK
Filling help tables...
OK

PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !
To do so, start the server, then issue the following commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h localhost.localdomain password 'new-password'

Alternatively you can run:
/usr/bin/mysql_secure_installation

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the MariaDB knowledge or the MySQL manual for more instructions.

You can start the MariaDB daemon with:
service mysqld start

You can test the MariaDB daemon with mariadb-bench package

Please report any problems with the /usr/scripts/mysqlbug script!

The latest information about MariaDB is available at http://www.askmonty.org/.
You can find additional information about the MySQL part at:
http://dev.mysql.com
Support MariaDB development by buying support/new features from
Monty Program Ab. You can contact us about this at sales@askmonty.org.
Alternatively consider joining our community based development effort:
http://askmonty.org/wiki/index.php/MariaDB#How_can_I_participate_in_the_development_of_MariaDB

Starting MySQL: ..,                                                                                                         [  OK  ]
[root@localhost mariadb-5.5.18]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.18-MariaDB Mageia - MariaDB Community Edition (GPL)

Copyright (c) 2000, 2011, Oracle and/or its affiliates.
2009-2011 Monty Program Ab

This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

(In reply to comment #5)
> (In reply to comment #4)
> > could this be due to systemd? 
> 
> Since Release 2 default is systemd, I would say it is.
> 
> I'll recommend you install VirtualBox, create a guest with a clean install,
> apply updates and see how it goes. :)

actually, afaik, it was decided that sysvinit would be the default, and that at this moment systemd would be set to default in cauldron, so it had proper testing.

perhaps systemd maintainer can take a look? (afaik mysql had the same issue)

Assignee: alien => qa-bugs
CC: (none) => alien, mageia

(In reply to comment #7)
> > Since Release 2 default is systemd, I would say it is.
> 
> actually, afaik, it was decided that sysvinit would be the default

When was this decided? I have not seen any announcement? If it's not going to be the default I'll stop trying to fix up all the issues with systemd+dracut etc. that I've been busy doing. I'd be most annoyed to hear I've been wasting my time.

(In reply to comment #7)

> actually, afaik, it was decided that sysvinit would be the default, and that at
> this moment systemd would be set to default in cauldron, so it had proper
> testing.

Well then, consider mairadb is failing the test. :(

> perhaps systemd maintainer can take a look? 

Hmmm, color me confused. If you look at my problem description, you might see
usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS

I would have expected the database to be created and filled in.

Still looking at the problem description, we find

/usr/bin/mysqld_safe --nowatch (code=exited, status=0/SUCCESS)

and yet, the database is still empty.  :(
# ls -al /var/lib/mysql/mysql
total 8
drwxr-xr-x 2 mysql mysql 4096 Dec 17 06:51 .
drwxr-xr-x 4 mysql mysql 4096 Dec 17 14:42 ..

(In reply to comment #8)
> (In reply to comment #7)
> > > Since Release 2 default is systemd, I would say it is.
> > 
> > actually, afaik, it was decided that sysvinit would be the default
> 
> When was this decided? I have not seen any announcement? If it's not going to
> be the default I'll stop trying to fix up all the issues with systemd+dracut
> etc. that I've been busy doing. I'd be most annoyed to hear I've been wasting
> my time.

i donno about this, but a long time ago, i thought it was set that systemd would wait until after mga1, and at mga2 times sysvinit would be default, with systemd option and mga3 would be systemd default?

i didn't think i saw any meetings where this was changed, but i can surely have missed them.

regardless, do you have any idea why the database would not be populated?

(In reply to comment #9)
> (In reply to comment #7)
> 
> > actually, afaik, it was decided that sysvinit would be the default, and that at
> > this moment systemd would be set to default in cauldron, so it had proper
> > testing.
> 
> Well then, consider mairadb is failing the test. :(

I was talking of systemd in that part of text (but my assumptions may have been wrong, i don't know)

> > perhaps systemd maintainer can take a look? 
> 
> Hmmm, color me confused. If you look at my problem description, you might see
> usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS
> 
> I would have expected the database to be created and filled in.
> 
> Still looking at the problem description, we find
> 
> /usr/bin/mysqld_safe --nowatch (code=exited, status=0/SUCCESS)
> 
> and yet, the database is still empty.  :(
> # ls -al /var/lib/mysql/mysql
> total 8
> drwxr-xr-x 2 mysql mysql 4096 Dec 17 06:51 .
> drwxr-xr-x 4 mysql mysql 4096 Dec 17 14:42 ..

i don't really know how systemd work... so i'm clueless here...

(why is this bug assigned to the QA ? :) )

I wanted to return it, but didn't remember the email that was in there before assigning. I thought it may have been this.

but imho, it's a systemd issue, without systemd it seems to work fine... and i have no clue on systemd at all.

actually, the init.d script seems to use mysql_install_db, but then mysqld-prepare-db-dir has similar code...

running that manually did populate the /var/lib/mysql/ directory...

can try to execute it manually? and tell me if it fails what the /var/log/mysql/mysqld.log file put in extra? and/or stderr output?

Assigning alien :) 

This shouldn't be assigned to QA team.

Assignee: qa-bugs => alien

(In reply to comment #8)
> (In reply to comment #7)
> > > Since Release 2 default is systemd, I would say it is.
> > 
> > actually, afaik, it was decided that sysvinit would be the default
> 
> When was this decided? I have not seen any announcement? If it's not going to
> be the default I'll stop trying to fix up all the issues with systemd+dracut
> etc. that I've been busy doing. I'd be most annoyed to hear I've been wasting
> my time.

we told and decided: 

systemd by default but we keep sysvinit compatibility for mageia 2
only systemd for mageia 3

Assignee: alien => qa-bugs

(In reply to comment #16)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > > Since Release 2 default is systemd, I would say it is.
> > > 
> > > actually, afaik, it was decided that sysvinit would be the default
> > 
> > When was this decided? I have not seen any announcement? If it's not going to
> > be the default I'll stop trying to fix up all the issues with systemd+dracut
> > etc. that I've been busy doing. I'd be most annoyed to hear I've been wasting
> > my time.
> 
> we told and decided: 
> 
> systemd by default but we keep sysvinit compatibility for mageia 2
> only systemd for mageia 3

btw: do you have any idea why even though mysqld-prepare-db-dir is in mysqld.service that it doesn't seem to have worked? and init.d style does work?

(In reply to comment #15)
> Assigning alien :) 
> 
> This shouldn't be assigned to QA team.

(i'm alien, and i think it's a systemd bug, or at least related, so i don't think it should be assigned to me... )

Assigning bugsquad.

Why was this re-re-assigned to QA?

This bug has nothing to do with QA team, please stop assigning it to qa-bugs!

See comment 15 :P

Assignee: qa-bugs => bugsquad

(In reply to comment #14)
> actually, the init.d script seems to use mysql_install_db, but then
> mysqld-prepare-db-dir has similar code...
> 
> running that manually did populate the /var/lib/mysql/ directory...
> 
> can try to execute it manually? and tell me if it fails what the
> /var/log/mysql/mysqld.log file put in extra? and/or stderr output?

Nothing.
# locate mysqld-prepare-db-dir
/usr/sbin/mysqld-prepare-db-dir

# /usr/sbin/mysqld-prepare-db-dir
# echo $?
0

# dir /var/log/mysqld/mysqld.log
-rw-r----- 1 mysql mysql 0 Dec 17 17:05 /var/log/mysqld/mysqld.log

huh... is this because it's sort of running? maybe?

can you do mysql_install_db and see if you get anything?

(In reply to comment #18)
> Assigning bugsquad.
> 
> Why was this re-re-assigned to QA?
> 
> This bug has nothing to do with QA team, please stop assigning it to qa-bugs!
> 
> See comment 15 :P

ah, thanks, i was looking for this email, i wish that bugzilla would have some kind of feature to give autocompletion... :-/

(In reply to comment #20)
> huh... is this because it's sort of running? maybe?

Nope. I have seen my 4'th fsck mounted 20 times check.
My logs were getting pretty big. Wrote a script to copy /dev/null over any log files.  :)

> can you do mysql_install_db and see if you get anything?

Yes, that did create the database.
systemctl start mysqld.service did bring the daemon on-line/active.

I've not looked at this problem yet, but will do shortly. I have seen similar failures in the past due to TMPDIR or HOME not being set. This is why TMPDIR is set in the /etc/sysconfig/mysql file, so it shouldn't be a problem in practice, but perhaps something's changed and the problem is kicking in? Anyway, just a guess for now before I can test properly.

(In reply to comment #21)
>> ah, thanks, i was looking for this email, i wish that bugzilla would have some
>> kind of feature to give autocompletion... :-/

>("Reset Assignee to default" https://bugs.mageia.org/show_bug.cgi?id=3797#assigned_to)

Keywords: Triaged => (none)

OK, so the problem is somewhat simple:

In the current version of the spec: 
http://svnweb.mageia.org/packages/cauldron/mariadb/current/SPECS/mariadb.spec?revision=183054&view=markup

Lines 716 include the folder /var/lib/mysql/mysql in the package.

In the prep script:
http://svnweb.mageia.org/packages/cauldron/mariadb/current/SOURCES/mysqld-prepare-db-dir?revision=166284&view=markup

Line 33 checks for the existence of that dir and does absolutely nothing if it exists.

So the packaging itself (the inclusion of empty /var/lib/mysql/mysql dir) prevents the preparation from working.


So that is the primary problem, however there also exists a second (theoretical) more subtle problem.

The prep script on line 46 runs:
/usr/bin/mysql_install_db --datadir="$datadir" --user=mysql

If this command returns a non-zero value, the return value of the script will be that value, however it may have left behind a partially built /var/lib/mysql/mysql folder (I don't know it's internals - perhaps this is guaranteed to not be the case and thus this theoretical problem is not a problem at all... but lets assume this is not the case).

Anyway, the first time "systemctl start mysqld.service" is run it will fail as the ExecStartPre failed. However due to the stale folder left behind, the second time it is called the ExecStartPre script will simply return 0 and wont attempt call the mysql_install_db script again.

I would recommend that if the script mysql_install_db bit fails, we should at least do something to indicate that it failed.

e.g. the following changes might be wise:


# Make the data directory
if [ ! -d "$datadir/mysql" -o -f "$datadir/.install-db-failed" ] ; then

    ...

    /usr/bin/mysql_install_db --datadir="$datadir" --user=mysql
    ret=$?
    chown -R mysql:mysql "$datadir"
    if [ $ret -ne 0 ] ; then
      touch "$datadir/.install-db-failed"
      exit $ret
    fi
    rm -f "$datadir/.install-db-failed"
  fi
fi


Or something along those lines.


Hope this helps.

NB you probably want a 'chown mysql:mysql "$datadir/.install-db-failed"' after the touch.

[the problem this would prevent against is someone running the script manually as root, having it fail, then running systemctl start mysqld.service which would run the script again, this time as the mysql user... maybe now the planets are aligned and the script runs OK, but sadly we cannot rm the install-db-failed file as it's owned by root.... grrrrr! Thus we will run the install_db script again next time, and the next time..... etc.]

Assign to maintainer now the cause is detailed.

Assignee: bugsquad => alien

can anyone test mariadb-5.5.18-0.bzr3169.20111216.5.mga2 i put in a possible fix, but don't have a systemd handy atm...

(In reply to comment #28)
> can anyone test mariadb-5.5.18-0.bzr3169.20111216.5.mga2 i put in a possible
> fix, but don't have a systemd handy atm...

You are package maintainer and mga2 will have systemd. You should have systemd to test if your package is ready to work with it or not.

CC: (none) => sander.lepik

(In reply to comment #29)
> (In reply to comment #28)
> > can anyone test mariadb-5.5.18-0.bzr3169.20111216.5.mga2 i put in a possible
> > fix, but don't have a systemd handy atm...
> 
> You are package maintainer and mga2 will have systemd. You should have systemd
> to test if your package is ready to work with it or not.

yes, I should. but I'm not always @home, & my chrooted tests don't cover systemd, & the bug in question is not systemd as such, so if i fix the script, it should work with systemd.

i don't think this is an unreasonable assumption, plus i'll test it when i get the chance anyway, but perhaps some users are fond of this and would prefer to know asap?

Please see comment 12, comment 15 and comment 18..

Assigning bugsquad (again)

Assignee: qa-bugs => bugsquad

(In reply to comment #28)
> can anyone test mariadb-5.5.18-0.bzr3169.20111216.5.mga2 i put in a possible
> fix, but don't have a systemd handy atm...

(In reply to comment #31)
> Please see comment 12, comment 15 and comment 18..
> 
> Assigning bugsquad (again)

Assigning back to maintainer.

@ Bit Twister
Can you confirm mariadb-5.5.18-0.bzr3169.20111216.5.mga2 (now in cauldron) fixes the bug. 

For me it does not work, but that could well be user error 
What I tried was only
$ systemctl start mysqld.service
and because that failed because of ..."No such file or directory"... I tried again
# systemctl start mysqld.service
But that gave the same error.
My /var/lib/mysql/mysql is just as empty as yours was.
And I get
$ systemctl status mysqld.service
mysqld.service
Loaded: error (Reason:No sucht file or directory)
Active: inactive (dead)

Assignee: bugsquad => alien
CC: (none) => marja11

I don't even understand the difference between mysqld and mysqld.service :(
Anyway, while mysqld.service is dead, mysqld runs happily.

(In reply to comment #33)
> I don't even understand the difference between mysqld and mysqld.service :(
> Anyway, while mysqld.service is dead, mysqld runs happily.

me neither... i just copied from mysqld, i know (next to) nothing about systemd.

in any case, i've tested by installing a mga2a2, installing mariadb only, (because the new rpm is supposed to have problems with filetriggers.)

i checked if the mysql dir was empty before i rebooted.

i rebooted and it was created and worked fine...

(In reply to comment #32)
> (In reply to comment #28)
> > can anyone test mariadb-5.5.18-0.bzr3169.20111216.5.mga2 i put in a possible
> > fix, but don't have a systemd handy atm...
> 
> (In reply to comment #31)
> > Please see comment 12, comment 15 and comment 18..
> > 
> > Assigning bugsquad (again)
> 
> Assigning back to maintainer.
> 
> @ Bit Twister
> Can you confirm mariadb-5.5.18-0.bzr3169.20111216.5.mga2 (now in cauldron)
> fixes the bug. 

Sorry for late response. Had to wait for new router.

Applied all updates, deleted  /var/lib/mysql/mysql/*, rebooted
urpme  --auto-orphans
y

systemctl start mysqld.service
no complaint

/usr/bin/mysqladmin -u root password 'TopSecret'
systemctl start httpd.service
firefox http://localhost/phpmyadmin
root
TopSecret

and was able to see all tables.

Works for me.

Thanks :)

So I'm the only one not managing to get it to work, but since I'm on i586 and this bug was filed against X86_64, it feels OK to close this bug as fixed.

If I were sure that I hadn't made an error while testing, I would set the Platform to "All" and leave this report open

Resolution: (none) => FIXED
Status: NEW => RESOLVED

considering the cause is arch independant, i'd say, if it still doesn't work on i586, that it's likely a different bug.

you could retest from a clean mga2a2 + upgrade and see what happens.