At URL, I committed a version of dev-db/{mysql,mariadb} featuring a systemd service unit in FILESDIR/ along with two support scripts. Both unit and support scripts have been taken from Fedora [1] and slightly adapted to run on Gentoo. I only tested mysql-5.5 and mariadb-5.5 and they work. [1] http://pkgs.fedoraproject.org/cgit/community-mysql.git/tree/ Reproducible: Always
This should probably added to dev-db/mysql-init-scripts instead. Much simpler to change. Could even do things like IUSE="+openrc systemd" REQUIRED_USE="^^ ( openrc systemd )" there.
Yeah, probably mysql-init-scripts is the right place. About the USE flag, that is wrong, we don't do that for systemd unit files nor for openrc init scripts. This has been discussed thousands of times on the mailing list already.
I just moved the systemd unit, the helper scripts and the tmpfiles.d conf to dev-db/mysql-init-scripts.
I am using the scripts from https://github.com/Sabayon/systemd-love/tree/master/dev-db/mysql-init-scripts/files they seems to work fine, great job. But to keep the functionality like openrc to run multiple slots: make it /usr/lib64/systemd/system/mysqld@.service and change ExecStart=/usr/bin/mysqld_safe to ExecStart=/usr/bin/mysqld_safe --defaults-file=/etc/mysql/%I.cnf this way a symlink mysqld.my.service would use /etc/mysql/my.cnf and mysqld.my2.service would use /etc/mysql/my2.cnf
commit 4c4233646731f84439134f48ae79144e96c0d991 Author: Fabio Erculiani <lxnay@sabayon.org> Date: Sun Apr 21 11:38:27 2013 +0100 [dev-db/mysql-init-scripts] allow slotted mysqld instances Done but I used /my%I.cnf so that "systemctl enable mysqld" keeps working.
Changes can be takedn from systemd-love overlay. I will commit in a week if nobody disagrees. Thanks
(In reply to Fabio Erculiani from comment #5) > commit 4c4233646731f84439134f48ae79144e96c0d991 > Author: Fabio Erculiani <lxnay@sabayon.org> > Date: Sun Apr 21 11:38:27 2013 +0100 > > [dev-db/mysql-init-scripts] allow slotted mysqld instances > > Done but I used /my%I.cnf so that "systemctl enable mysqld" keeps working. $ sudo systemctl enable mysqld Failed to issue method call: No such file or directory $ sudo systemctl enable mysqld@.service ln -s '/usr/lib64/systemd/system/mysqld@.service' '/etc/systemd/system/multi-user.target.wants/mysqld@.service'
(In reply to Alexander Tsoy from comment #7) And then: $ sudo systemctl start mysqld@.service Failed to issue method call: Unit name mysqld@.service is not valid. So I think ebuild shoud install two units: mysqld@.service and mysqld.service
(In reply to Alexander Tsoy from comment #8) > (In reply to Alexander Tsoy from comment #7) > > And then: > > $ sudo systemctl start mysqld@.service > Failed to issue method call: Unit name mysqld@.service is not valid. > > So I think ebuild shoud install two units: mysqld@.service and mysqld.service Probably, if you could provide a diff would be really appreciated :)
(In reply to Pacho Ramos from comment #9) Just apply this patch reversed and you will get the original mysqld.service :) https://github.com/Sabayon/systemd-love/commit/4c4233646731f84439134f48ae79144e96c0d991#diff-1 Also mysqld-prepare-db-dir script is not compatible with the mysqld@.service.
(In reply to Alexander Tsoy from comment #10) > Also mysqld-prepare-db-dir script is not compatible with the mysqld@.service. It always initialize db in /var/lib/mysql.
(In reply to Alexander Tsoy from comment #10) > Also mysqld-prepare-db-dir script is not compatible with the mysqld@.service. I guess more work will be needed still. Also, reverting the systemd-love commit will lose slot support, is that wanted?
(In reply to Pacho Ramos from comment #12) > (In reply to Alexander Tsoy from comment #10) > > Also mysqld-prepare-db-dir script is not compatible with the mysqld@.service. > > I guess more work will be needed still. This script should not be too smart - initializing of the DB is not its work. For example /var/lib/mysql can be a mounting point that is not mounted for some reason. In that case the unit must fail. So I would prefer that "mysqld-prepare-db-dir" is based on our init script (then it should be named "mysqld-check-db-dir"). Are there any objections? > Also, reverting the systemd-love commit will lose slot support, is that wanted? I just pointed you to the diff between original mysqld.service and template unit mysqld@.service. I didn't mean that you should delete the latter. :)
(In reply to Alexander Tsoy from comment #13) > (In reply to Pacho Ramos from comment #12) > > (In reply to Alexander Tsoy from comment #10) > > > Also mysqld-prepare-db-dir script is not compatible with the mysqld@.service. > > > > I guess more work will be needed still. > > This script should not be too smart - initializing of the DB is not its > work. For example /var/lib/mysql can be a mounting point that is not mounted > for some reason. In that case the unit must fail. So I would prefer that > "mysqld-prepare-db-dir" is based on our init script (then it should be named > "mysqld-check-db-dir"). > > Are there any objections? And what is the benefit of doing that check? Doesn't mysqld fail on its own when there is no config or database?
(In reply to Michał Górny from comment #14) > And what is the benefit of doing that check? Doesn't mysqld fail on its own > when there is no config or database? With empty datadir mysqld fails to start, but it creates some files in it =/ $ sudo ls -a /var/lib/mysql . .. aria_log.00000001 aria_log_control ibdata1 ib_logfile0 ib_logfile1 Also this script is for convenience. If you start mysqld service without any checks and with an empty datadir, then you get these uninformative messages in the journal: Aug 27 13:31:58 HOSTNAME systemd[1]: Starting MySQL database server... Aug 27 13:31:59 HOSTNAME mysqld_safe[26951]: 130827 13:31:59 mysqld_safe Logging to '/var/log/mysql/mysqld.err'. Aug 27 13:31:59 HOSTNAME mysqld_safe[26951]: 130827 13:31:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql Aug 27 13:32:01 HOSTNAME mysqld_safe[26951]: 130827 13:32:01 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended Aug 27 13:32:02 HOSTNAME systemd[1]: mysqld.service: control process exited, code=exited status=1 Aug 27 13:32:02 HOSTNAME systemd[1]: Failed to start MySQL database server. Aug 27 13:32:02 HOSTNAME systemd[1]: Unit mysqld.service entered failed state.
Why is there so much talk on this bug? Just provide a mysqld.service and we're fine. At the time, when I tested both scenarios, everything was working fine for me. Moreover, the setup code in the init script is overkill. The Fedora way is the right one wrt supporting multiple init systems. So, my advice is: just take mysqld@.service and write mysqld.service and close the bug.
+*mysql-init-scripts-2.0_pre1-r4 (03 Sep 2013) + + 03 Sep 2013; Pacho Ramos <pacho@gentoo.org> +files/mysql.conf, + +files/mysqld-prepare-db-dir, +files/mysqld-wait-ready, +files/mysqld.service, + +files/mysqld_at.service, +mysql-init-scripts-2.0_pre1-r4.ebuild: + Add systemd support (#466084) +
*** Bug 488896 has been marked as a duplicate of this bug. ***
*** Bug 498962 has been marked as a duplicate of this bug. ***
