Probably caused by change for "Log files are not config files" - https://bugzilla.redhat.com/show_bug.cgi?id=1043501 - http://pkgs.fedoraproject.org/cgit/mariadb.git/commit/?h=f20&id=7e95015252688d603e77fef488f3cca47f67623f

Attila, thanks for reporting. I see that /var/log/mariadb/mariadb.log has root:root owner in your case, which is simply wrong. Have you changed that manually? Otherwise I cannot understand how this could happen, since all systemd processes from mariadb run as mysql user.

To make it clear -- you installed mariadb-server on a machine where no such package was installed before?

Anyway, these are correct privileges and SELinux context that the log file and its directory should have:

# ls -ldZ /var/log/mariadb/
drwxr-x---. mysql mysql system_u:object_r:mysqld_log_t:s0 /var/log/mariadb/
# ls -ldZ /var/log/mariadb/mariadb.log
-rw-r-----. mysql mysql system_u:object_r:mysqld_log_t:s0 /var/log/mariadb/mariadb.log

First I noticed the issue in automated run with the official fedora-20 cloud image  (before the job reaches the mariadb installation part, the job does a yum update and a reboot ).
As you can see in the bug report the file created at yum install time, I even did not tried to start the service. 
It was reproduced on the f20 cloud image manually as you can see above.

The issue introduced by the mariadb-server.x86_64 1:5.5.34-3.fc20, the job was ok with the mariadb-server.x86_64 1:5.5.34-2.fc20.

Another strange issue, the service at start up tries to correct the permission issue, but it does not have enough permission for fixing that.

(Even if the selinux is in a permissive mode.)

NOTE: So if anything/anyone configures a new log file location, the file might not be created automatically and the service will fail to start.

Just ran into this myself. Starting clean:

# ls -la /var/log/mariadb
ls: cannot access /var/log/mariadb: No such file or directory

and installing the latest spin:
# rpm -ivv mariadb-server-5.5.35-1.fc20.x86_64.rpm

results in the observed:
# ls -l /var/log/mariadb/mariadb.log 
-rw-r--r-- 1 root root 0 Feb  4 11:34 /var/log/mariadb/mariadb.log

because of
%post
+ /bin/touch /var/log/mariadb/mariadb.log

per
http://pkgs.fedoraproject.org/cgit/mariadb.git/tree/mariadb.spec?h=f20#n575


I'm not sure how much of that %post applies now that the logfiles are %ghost. If I emulate that touch not existing with a manual
# rm /var/log/mariadb/mariadb.log

then everything starts fine...

(In reply to Aaron Richton from comment #4)
> %post
> + /bin/touch /var/log/mariadb/mariadb.log

Aaah, good cache. The problem is that for ghost files setting of owner/permissions in %files section doesn't apply actually, so when touching the log in the %post section, it ends really with root:root owner. Will fix soon. Thanks for elaboration.

mariadb-5.5.35-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mariadb-5.5.35-3.fc20

mariadb-5.5.35-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mariadb-5.5.35-2.fc19

*** Bug 1062054 has been marked as a duplicate of this bug. ***

Package mariadb-5.5.35-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mariadb-5.5.35-3.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2119/mariadb-5.5.35-3.fc20
then log in and leave karma (feedback).

*** Bug 1063499 has been marked as a duplicate of this bug. ***

Please note that at least in my case, the old log file must be manually removed before installing 5.5.35-3 in-order to fix this bug.

- Gilboa

mariadb-5.5.35-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

mariadb-5.5.35-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

I still have the problem on Fedora 20. 

[root@fedorahost pablo]# ls -ldZ /var/log/mariadb/mariadb.log
ls: cannot access /var/log/mariadb/mariadb.log: No such file or directory
[root@fedorahost pablo]# ls -ldZ /var/log/mariadb/
ls: cannot access /var/log/mariadb/: No such file or directory

I install mariadb 

Installed:
  mariadb.x86_64 1:5.5.35-3.fc20                                                                                                                                                                                                             
Complete!

service mariadb status
Redirecting to /bin/systemctl status  mariadb.service
mariadb.service
   Loaded: not-found (Reason: No such file or directory)
   Active: failed (Result: exit-code) since Sat 2014-02-15 22:29:38 GMT; 3min 29s ago
 Main PID: 4126 (code=exited, status=1/FAILURE)

Feb 15 22:29:37 fedorahost.fedoradomain mysqld_safe[4126]: touch: cannot touch ‘/var/log/mysqld.log’: Permission denied
Feb 15 22:29:37 fedorahost.fedoradomain mysqld_safe[4126]: chown: cannot access ‘/var/log/mysqld.log’: No such file or directory
Feb 15 22:29:37 fedorahost.fedoradomain mysqld_safe[4126]: chmod: cannot access ‘/var/log/mysqld.log’: No such file or directory
Feb 15 22:29:37 fedorahost.fedoradomain mysqld_safe[4126]: 140215 22:29:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Feb 15 22:29:37 fedorahost.fedoradomain mysqld_safe[4126]: /usr/bin/mysqld_safe: line 138: /var/log/mysqld.log: Permission denied
Feb 15 22:29:37 fedorahost.fedoradomain systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
Feb 15 22:29:38 fedorahost.fedoradomain systemd[1]: mariadb.service: control process exited, code=exited status=1
Feb 15 22:29:38 fedorahost.fedoradomain systemd[1]: Failed to start MariaDB database server.
Feb 15 22:29:38 fedorahost.fedoradomain systemd[1]: Unit mariadb.service entered failed state.
Feb 15 22:30:27 fedorahost.fedoradomain systemd[1]: Stopped MariaDB database server.

[root@fedorahost pablo]# ls -ldZ /var/log/mariadb/mariadb.log
ls: cannot access /var/log/mariadb/mariadb.log: No such file or directory

[root@fedorahost pablo]# service mariadb start 
Redirecting to /bin/systemctl start  mariadb.service
Failed to issue method call: Unit mariadb.service failed to load: No such file or directory.

[root@fedorahost pablo]# ls -ldZ /var/log/mariadb/mariadb.log
ls: cannot access /var/log/mariadb/mariadb.log: No such file or directory

ls -laZ /var/log/mariadb
ls: cannot access /var/log/mariadb: No such file or directory

Sorry, now the problem is different. Anyway:
ls -laZ /var/log/mysqld.log
ls: cannot access /var/log/mysqld.log: No such file or directory

I could not reproduce the error again, so maybe was a typo. Do not open the bug again unless somebody else has the same error.

Just if anybody has the same problem: the reason of Comments 15 and 16 was this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1066112

There are still issues here to be looked at.
Log files are not generated properly for mariadb to start or restart.

Thanks

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.