hi Restart=always triggers restart even after manual stop of a service this can not be the required behavior because i expect that a service is started in this case if anything/anybody outside systemd kills the process but not after a manual stop via systemctl ________________________ [root@testserver:~]$ cat /lib/systemd/system/mysqld.service [Unit] Description=MySQL Database After=sockets.target syslog.target Before=httpd.service postfix.service [Service] Type=simple PIDFile=/var/run/mysqld/mysqld.pid ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --user=mysql ExecStop=/bin/kill -15 $MAINPID Restart=always RestartSec=2 TimeoutSec=60 [Install] WantedBy=multi-user.target Also=mysqld.socket ________________________ [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: active (running) since Sun, 19 Jun 2011 23:37:57 +0200; 1min 34s ago Main PID: 850 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 850 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl stop mysqld.service [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: deactivating (stop-sigterm) since Sun, 19 Jun 2011 23:39:37 +0200; 2s ago Process: 1648 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 850 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 850 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: active (running) since Sun, 19 Jun 2011 23:39:41 +0200; 1s ago Process: 1648 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1652 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 1652 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: active (running) since Sun, 19 Jun 2011 23:39:41 +0200; 2s ago Process: 1648 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1652 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 1652 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: active (running) since Sun, 19 Jun 2011 23:39:41 +0200; 3s ago Process: 1648 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1652 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 1652 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl stop mysqld.service [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: deactivating (stop-sigterm) since Sun, 19 Jun 2011 23:42:34 +0200; 1s ago Process: 1703 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1652 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 1652 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: deactivating (stop-sigterm) since Sun, 19 Jun 2011 23:42:34 +0200; 3s ago Process: 1703 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1652 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 1652 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock... [root@testserver:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/lib/systemd/system/mysqld.service) Active: active (running) since Sun, 19 Jun 2011 23:42:38 +0200; 623ms ago Process: 1703 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1709 (mysqld) CGroup: name=systemd:/system/mysqld.service └ 1709 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock...
I tried reproducing this with dovecot in F-15. I added: Restart=always RestartSec=2 TimeoutSec=60 to the shipped unit file and did 'systemctl daemon-reload'. I was able to start and stop the service without any unexpected restarts. I see you also added an associated socket unit mysqld.socket. Is it possible that mysqld.service gets restarted due to socket activation via this socket? I recommend booting with systemd.log_level=debug and looking at /var/log/messages when debugging unit files.
> I see you also added an associated socket unit mysqld.socket. Is it possible > that mysqld.service gets restarted due to socket activation via this socket? possible - but this socket is really needed because you drive in real troubles if you have dbmail, postfix, dovecot or with other words a fully mysql-driven infrastructure and "systemd" fires up other services before mysqld is ready for connections however - if "systemctl stop service "is given in really no case/configuration systemd should be allowed to start the service - in the case of mysql if you run on a backup-host horuly rsync-copies of a mysqld-slvae to the normally running mysqld (both services on the same machine) and anything fires up the mysqld which datafiles are synchronized you have a real problem the hughe dependencies of our infrastrcucture and the fact that package-maintainers did ignore systemd without realize the results and the not understandable decision not porting missing services from sysvinit to systemd are making it really importnt for me/our small company to get mysqld rock solid running with auto-restarts and relieable as all the years before
Does it work as expected if you do this?: systemctl stop mysqld.socket mysqld.service
yes, but this is really bad usability because systemd MUST NOT wake up a manually stopped service for whatever reason - please make it a little bit smarter and at lest it could print a warning BTW: why does "systemctl stop service" and "systemctl start service" give no feedback? i expect an answer from a system instead need "systemctl stp mysqld.socket mysqld.service" followed "bei systemctl status mysqld.service" to find out if this has worked over all the years i laughed about the CLI tools on macosx for managing servcies and their wired order "start/stop/status service" and now we get this on linux with the same mistakes?
(In reply to comment #4) > yes, but this is really bad usability because systemd MUST NOT wake up a > manually stopped service for whatever reason - please make it a little bit > smarter and at lest it could print a warning You may find article helpful: http://0pointer.de/blog/projects/three-levels-of-off You may have a point about the printing of a warning. In the case of manual stopping of a service that has an associated active (listening) socket, it is likely that the user simply forgot about the possibility of socket activation and the warning would help him realize it. It would still not cover all activation possibilities though. [Changing the Summary.]
> it is likely that the user simply forgot about the > possibility of socket activation and the warning would > help him realize it it is simply poor usability design of systemd that the user has to care it is also poor that "systemctl start/stop/restart" gives no feedback it is also poor that at boot time OK/FAILED has no colors as upstart had it is also poor design that you see no progress while fsck is running at boot time guys your definition of usability is very very strange!
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Given that we will be only back porting important fixes for F15 at this point in time I'm moving this RFE against Rawhide so it does not get forgotten or lost in the EOL process.
Rawhide = F17/F18 this made me crazy for some hours after trying to debug mysqld on F15 please backport it at least for F16!
http://cgit.freedesktop.org/systemd/systemd/commit/?id=701cdcb9ee846b3d1629b55a11c61a3343af4874
systemd-44-14.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-14.fc17
For Rawhide the fix is in systemd-185-6.gite7aee75.fc18
Package systemd-44-14.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-14.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9471/systemd-44-14.fc17 then log in and leave karma (feedback).
systemd-44-14.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.