Our binary tarballs are built on far older machines than those that have systemd support. Do we have an urgent need to have it in bintars?

I don't know if there's an urgent need. I just had a user run into this problem today, but that was the first time that I had seen anyone complain about this.

I didn't realize that systemd was a compile-time dependency, but I see now that mysqld is linked to some systemd-related shared library on systems that support it.

[ec2-user@ip-172-31-19-192 ~]$ ldd /usr/sbin/mysqld | grep "systemd"

        libsystemd-daemon.so.0 => /lib64/libsystemd-daemon.so.0 (0x00007fe942686000)

[ec2-user@ip-172-31-19-192 ~]$ rpm -q MariaDB-server

MariaDB-server-10.1.11-1.el7.centos.x86_64

[ec2-user@ip-172-31-19-192 ~]$ ldd mariadb-10.1.12-linux-x86_64/bin/mysqld | grep "systemd"

The user I spoke with today was using systemd along with a bintar installation. Is it likely to cause problems for that user that the server is not linked to systemd?

Let's ask svoj about this last concern.

For the fix, it's simple – if we really need it, we'll have to start building bintars on a newer system; and I'm not sure we can drop the old ones for 10.1 easily, so most likely we'll have to maintain three pairs of bintars instead of two which we have now, which is of course additional fuss.
We probably could do it for 10.2 though, now would be a good time to decide. serg, what do you think? Do we want to keep building bintars for 10.2 on the stone-age Centos 5 and Quantal which EOL-ed 2 years ago, or should we switch to newer builders while we can?

I think we can move bintars from Quantal to something newer. CentOS will continue building old-glibc bintars for whoever needs them and newer-glibc build can happen on a newer distro. Those, who used quantal bintars, will either use newer-glibc bintars or will switch to old-glibc bintars.

Assigning to svoj to answer the question above and also to provide opinion on building bintars with systemd support.

We kept SysVinit stuff, so there should be no big problems. Roughly speaking running non-systemd 10.1 should be in no way more problematic as running 10.0.

Since systemd stuff has extra depenencies, it can't replace generic bintars (e.g. Devuan is there only thanks to absence of systemd). Having extra bintars with systemd support is fine.

Assigning to serg for the final decision regarding bintars. If the decision is to switch from Quantal to something newer, I suppose the task will be further passed over to dbart.

Is trusty new enough? We could upgrade quantal to trusty, if it is. Better to stay on LTS anyway.
dbart, what would you say?

serg Trusty should work just fine for building bintars. Will we be removing the quantal builder and replacing it with trusty or will we just be adding trusty as a third bintar builder?

Also – are we replacing centos5 with anything? It will go EOL soon too.

dbart, thanks. Could you add a pair of trusty-based bintar builders? Let's keep quantal builders too for now, they'll continue building, we just won't offer these builds at download.mariadb.org. Download pages might need to be updated to say the correct glibc version, if trusty has a newer one.

elenst, I think we could keep CentOS5 builders for a while. Quantal also worked well beyond EOL, it wasn't a problem.

The trusty-bintar builder is in place, but it is currently reporting the following error:

CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):

  Could NOT find GnuTLS: Found unsuitable version "2.12.23", but required is

  at least "3.3.24" (found /usr/lib/x86_64-linux-gnu/libgnutls.so)

Full log: http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-trusty-amd64/builds/29/steps/compile/logs/stdio

serg: I think you were the one that installed gnutls under /usr/local/ on the quantal-bintar builders, did you do anything special? If not, I can handle installing it on the trusty-build VMs (I'm guessing you just compiled it from source). If there is anything special that needs to be done when installing it, please let me know. Thanks!

I've built static gnutls and installed it to the trusty builders and triggered rebuilds. Now monitoring to see if they will successfully build.

The trusty-amd64-bintar and trusty-x86-bintar builders are now successfully building MariaDB 10.2, and both the 10.1 and 10.2 tarballs now being produced by buildbot have systemd files:

$ tar -tzvf mariadb-10.2.4-linux-x86_64.tar.gz | grep "systemd"

mariadb-10.2.4-linux-x86_64/support-files/systemd/mariadb@.service

mariadb-10.2.4-linux-x86_64/support-files/systemd/use_galera_new_cluster.conf

mariadb-10.2.4-linux-x86_64/support-files/systemd/mariadb.service

mariadb-10.2.4-linux-x86_64/include/mysql/private/my_systemd.h

$ tar -tzvf mariadb-10.1.22-linux-x86_64.tar.gz | grep "systemd"

mariadb-10.1.22-linux-x86_64/support-files/systemd/mariadb@.service

mariadb-10.1.22-linux-x86_64/support-files/systemd/use_galera_new_cluster.conf

mariadb-10.1.22-linux-x86_64/support-files/systemd/mariadb.service

mariadb-10.1.22-linux-x86_64/include/mysql/private/my_systemd.h

These new bintars with systemd will appear in the next 10.1 and 10.2 releases.

If there's nothing else for this task I'll close it.

Fix will be in the next releases of 10.2 and 10.1. Bintars with systemd will be named after the following pattern:

mariadb-<version>-systemd-<arch>.tar.gz

I missed the file ./support-files/systemd/mariadb.service file also in version 10.3.14.
In version 10.3.11 it was still there. Therefore I plan to use the one from the tarball mariadb-10.3.11-linux-systemd-x86_64.tar.gz and just changed the version in the description. Is there anything else that have to be considered ?