Created attachment 748800 [details] A patch for mediatomb.service to run after mysqld.service Description of problem: Mediatomb uses SQLite as its' default database frontend, but it also supports MySQL. When mysql server and mediatomb are on the same computer, mediatomb has to wait for mysqld.service before it can start. So there has to be another systemd unit, say mediatomb-mysql.service, which contains mysqld.service in After= string. Or, maybe it is better to modify the existing mediatomb.service, so that it always starts after mysqld.service. Version-Release number of selected component (if applicable): mediatomb-0.12.1-26.fc18.20120403gitb66dc1 How reproducible: Choose mysql as a database frontend in mediatomb/config.xml. Steps to Reproduce: 1. Install mysql-server. 2. Install mediatomb. 3. Setup mysql database for mediatomb. 4. Configure mediatomb to use mysql database instead of the default sqlite. 5. Enable mysqld.service and mediatomb.service. 6. Reboot. Actual results: Mediatomb service fails to launch, because mysql service is not yet running. Expected results: Mediatomb service launches after mysql. Additional info:
Modifying the existing mediatomb.service to After= mysql will cause it to fail if mysqld isn't installed and set to start by default. A mediatomb-mysql.service would work for locally running mysqld but potentially suffer the same problem for a remotely running mysqld. I'll see about putting something together and posting it for you to test.
I assume you'd like f18 builds to test, 32 or 64 bit?
Thank you Jon, I've got 32 bit installations. You say that putting some service in After= of another service tends to failure of the latter if the former is not installed or set to start. I also thought so, but the man page of systemd.unit (5) says that After= is not the same as Require=. The latter sets the dependency, while the former is only sets the boot priority. I have just tried to run self made mediatomb-mysql.service from /usr/local/systemd/system, with mysqld.service stopped. And it has run OK without any error message. Mediatomb has been configured, of course, to use SQLite prior to it to avoid problems.
But I've not tried to run with mysql server not installed. You are right that potential problem still remains if mysql server is remote. But it seems that it is not a responsibility of systemd in such situation to cope with remote server dependency, but of mediatomb.
You're right, though it's actually the admin's problem. :) Testing without mysql-server installed is really what's needed. I was thinking that putting After=mysqld.service in the main .service would be OK, but it could unneccesarily delay mediatomb startup in cases where mysql-server is installed but not set to run at boot. Here's a 32-bit f18 build with two .service files. http://fedorapeople.org/~limb/mediatomb/
How is this working?
Jon, please, excuse me for a silence. It worked all right on Fedora 18. Thank you. Now it is time for Fedora 19. Could you update a package for it.
mediatomb-0.12.1-29.fc19.20120403gitb66dc1 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mediatomb-0.12.1-29.fc19.20120403gitb66dc1
mediatomb-0.12.1-29.fc18.20120403gitb66dc1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mediatomb-0.12.1-29.fc18.20120403gitb66dc1
Package mediatomb-0.12.1-29.fc19.20120403gitb66dc1: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mediatomb-0.12.1-29.fc19.20120403gitb66dc1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12784/mediatomb-0.12.1-29.fc19.20120403gitb66dc1 then log in and leave karma (feedback).
mediatomb-0.12.1-29.fc18.20120403gitb66dc1 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
mediatomb-0.12.1-29.fc19.20120403gitb66dc1 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.