see also http://svnweb.mageia.org/packages/cauldron/mariadb/current/SOURCES/mysqld.service?view=log for mysqld.service script from mageia

More links do downstream versions:

OpenSUSE: https://build.opensuse.org/package/view_file/server:database/mariadb/mysql.service?expand=1

Fedora (uses two service files):
http://pkgs.fedoraproject.org/cgit/mariadb.git/tree/mysql.service.in
http://pkgs.fedoraproject.org/cgit/mariadb.git/tree/mysql-compat.service.in

Arch: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/mariadb.service?h=packages/mariadb

These are all different. They all even use different service names: mysql, mysqld, mariadb and mysql+mysql-compat.

I'll do one for Debian once I figure out what the optimal service file should look like.

It's possible to use one main service name and then configure an alias (in the units) as appropriate for each distro.

We should not waste time with broken examples.
i.e. the SUSE stuff:

[Service]

Type=forking

ExecStart=/usr/lib/mysql/rcmysql start

ExecStop=/usr/lib/mysql/rcmysql stop

This is broken. You use systemd to start the binary.
systemd takes care
To stop a SIGTERM is sufficient
Using mysqld_safe is also forbidden.
systemd takes care of restarting a service.

I had an look at the mariadb package from fedora20 and changed it

[Unit]

Description=MariaDB database server

After=syslog.target

After=network.target

[Service]

# It is all default just for documentation

Type=simple

User=mysql

Group=mysql

# Removed that on. Should be done in the package

#ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n

# Changed from mysqld_safe to mysql

ExecStart=/usr/libexec/mysqld

# Makes no real sense to wait for the mainpid we already control it

#ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID

# Just defining the was how to kill mysqld.

KillMode=process

KillSignal=SIGTERM

# Thats me I don't want to see an automated SIGKILL ever

SendSIGKILL=no

# I hate timeouts. Most likely sysadmins use them and revert my SendSIGKILL

#TimeoutSec=300

# We restart mysqld if there is a failure (5s delay)

Restart=on-failure

RestartSec=5s

PrivateTmp=true

[Install]

# So we can use mysql and mariad as service

Alias=mysql.service

WantedBy=multi-user.target

"Makes no real sense to wait for the mainpid we already control it"

I disagree. With a Type=simple service, systemd considers the service fully running as soon as systemd starts running ExecStart. This is problematic if other services depend on MariaDB and need to run after its fully online.

for mageia, i would like to change this to not use mysqld_safe either...

anyway, i'm open to suggestions...

In our environment we have about 1000 mariadb/mysql databases. It takes a few minutes for everything to fully come up and be ready to serve connections. The redhat service file includes a ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID bit where that script loops with "/usr/bin/mysqladmin --no-defaults --socket="$socketfile" --user=UNKNOWN_MYSQL_USER ping" until it can successfully connect (not successfully login, just connect). Something like that will probably be required to ensure the service is really up.

mchugh19 The old init scripts have a section that waits for service to come up (and also to stop at shutdown/restart) which uses the mysqld_status command. See http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/tree/debian/mariadb-server-10.0.mysql.init

Others: http://0pointer.net/public/systemd-nluug-2014.pdf presents the systemd security features, which are encouraged (at least in Debian) to be used.

Hmm,
Both do the same in the end.
Imho it is embarrassing to have still no systemd integration at all.
The whole world takes MariaDB into there distribution. systemd is going to be the PID 1
and MariaDB is not able to get this done.

Avoided all deficiencies of type=

by using Type=Notify in MDEV-5536. Thanks for the base service file erkules. I've also seen a possibility of doing database install like sshd-keygen.service (https://bugzilla.redhat.com/show_bug.cgi?id=1066615#c7).

Oh notify is indeed a very nice opportunity. Making it not that "simple" anymore

Making things more complex:
I would like to agree on how/when to initialise datadir.
Like Debian/Ubuntu on installation or on startup.

Btw: As with 10.1 and integrated Galera we need to take care of --wsrep-recover's job in mysqld_safe also

initialisations support-files/mariadb-systemd-start make it as late as possible, hopefully my.cnf files are populated by the time a user starts a service.

wsrep-recover -looks like its something that should be moved into mysqld rather than running mysqld, extracting output and running mysqld again.

https://github.com/MariaDB/server/pull/26 included systemd script

This effectively prevents me from using MariaDB Galera in Debian Jessie since it's not possible to bootstrap the cluster without launching mysqld manually with the --wsrep-new-cluster, which will subsequently prevent managing the service through systemd.

nils.meyer yeh, perhaps having a type=oneshot or different service for that specific purpose that isn't part of the default. I'll see what I can make up. Quite a few things to consider for that however.

I'll add them on top of the current pull request.

https://github.com/MariaDB/server/pull/83

nils.meyer - MDEV-7752 - focuses on Centos7 however something might be applicable for you.

would it be possible to ship that for 10.0 as well?

We'd love to. But as it turned out, users don't like when we add new dependencies to our packages in a GA branch (yes, we've tried). And in these patches MariaDB is linked with libsystemd-daemon.so, so we'll have to add it as a dependency. We cannot do that. I see few options for 10.0:

• add the patch nevertheless, but build our packages without systemd. Users would need to compile MariaDB to get systemd support.
• bundle libsystemd-daemon sources with 10.0
• only implement a minimal systemd support in 10.0 that doesn't require changes in the server

What do you think we should do?

Either way, I think we'll add systemd support in 10.1 first and then, possibly, backport parts of it to 10.0

Sergei,

I would suggest the third choice, aka minimal systemd support. This is the less intrusive, and to be honest, most people just need minimal support.
Let's keep the systemd socket activation for 10.1 as it introduces major changes.

Regards,
Guillaume

I agree with serg about being conservative in GA branches. Add well documented systemd scripts to 10.1 and downstream packagers can then choose themselves if they want to take the risk of backporting it somewhere, e.g. to new OS/Linux distro releases.