Bug 714525 - RFE: systemctl could warn when asked to stop a service while the associated socket is still listening
RFE: systemctl could warn when asked to stop a service while the associated s...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-06-19 17:44 EDT by Harald Reindl
Modified: 2012-06-20 15:25 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 15:25:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harald Reindl 2011-06-19 17:44:32 EDT
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...
Comment 1 Michal Schmidt 2011-06-20 10:24:33 EDT
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.
Comment 2 Harald Reindl 2011-06-20 17:51:17 EDT
> 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
Comment 3 Michal Schmidt 2011-06-21 05:08:27 EDT
Does it work as expected if you do this?:
  systemctl stop mysqld.socket mysqld.service
Comment 4 Harald Reindl 2011-06-21 06:27:29 EDT
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?
Comment 5 Michal Schmidt 2011-06-21 07:24:39 EDT
(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.]
Comment 6 Harald Reindl 2011-07-22 13:51:26 EDT
> 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!
Comment 7 Fedora Admin XMLRPC Client 2011-10-20 12:29:15 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Jóhann B. Guðmundsson 2012-02-20 06:36:08 EST
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.
Comment 9 Harald Reindl 2012-02-20 06:42:56 EST
Rawhide = F17/F18

this made me crazy for some hours after trying to debug mysqld on F15
please backport it at least for F16!
Comment 11 Fedora Update System 2012-06-14 19:14:33 EDT
systemd-44-14.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-14.fc17
Comment 12 Michal Schmidt 2012-06-14 19:18:13 EDT
For Rawhide the fix is in systemd-185-6.gite7aee75.fc18
Comment 13 Fedora Update System 2012-06-15 08:28:37 EDT
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).
Comment 14 Fedora Update System 2012-06-20 15:25:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.