Bug 700341 - unable to stop mysqld service
Summary: unable to stop mysqld service
Keywords:
Status: CLOSED DUPLICATE of bug 699114
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 701362 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-28 07:45 UTC by Alexander Dyadyun
Modified: 2011-05-10 21:08 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-28 19:01:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexander Dyadyun 2011-04-28 07:45:05 UTC
Description of problem:
I am unable to stop mysqld service.

Version-Release number of selected component (if applicable):
mysql.x86_64 5.5.10-2.fc15

How reproducible:
Rock solid

Steps to Reproduce:
1. yum install mysql-server
2. service mysqld start
3. service mysqld stop
  
Actual results:
Stopping mysqld (via systemctl)....
waiting for 5 minutes and then press ^C
system hangs at shutdown

Expected results:
Stopping mysqld (via systemctl) [OK]
poweroff or reboot system without problems

Additional info:
Hardware: Virtual machine on qemu 0.14 (1CPU/768Mb RAM/8Gb vda)
OS: Clean install of Fedora 15 beta (x86_64) in minimal config

Comment 1 Tom Lane 2011-04-28 18:55:34 UTC
What I see here is that in fact mysqld terminates, but the "service mysqld stop" command never comes back.   ps -efjH shows interesting information:

root     15909 15527 15909 15527  0 14:37 pts/0    00:00:00           sudo service mysqld stop
root     15910 15909 15909 15527  0 14:37 pts/0    00:00:00             /bin/sh /sbin/service mysqld stop
root     15918 15910 15909 15527  0 14:37 pts/0    00:00:00               /bin/sh /etc/init.d/mysqld stop
root     15924 15918 15909 15527  0 14:37 pts/0    00:00:00                 /bin/systemctl stop mysqld.service
root     15925 15924 15909 15527  0 14:37 pts/0    00:00:00                   /bin/systemd-tty-ask-password-agent --watch

(Note that I'm doing this in an incoming ssh session, not from the machine's desktop)

So the first question is what the heck is systemctl doing here at all (the mysql init script most certainly didn't try to run that), and the second question is why is it trying to get a password, and the third question is why is it trying to get the password from the wrong place, and the fourth is why is it doing so after the useful work is already done?

BTW, it does eventually time out, after about 15 minutes (didn't measure it exactly), and return a success indication:

[tgl@rhl ~]$ sudo service mysqld stop
Stopping mysqld (via systemctl):                           [  OK  ]
[tgl@rhl ~]$

Comment 2 Michal Schmidt 2011-04-28 19:01:15 UTC

*** This bug has been marked as a duplicate of bug 699114 ***

Comment 3 Tom Lane 2011-04-28 19:11:47 UTC
I tried the same experiment with postgresql.    The "stop" works, which quite surprised me since I would've expected systemctl to have even less of a clue about stopping postgres than mysql.  However, the initial "start" is pretty unfriendly:


[tgl@rhl ~]$ sudo service postgresql start
Starting postgresql (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                           [FAILED]
[tgl@rhl ~]$ 

In previous versions you got a useful message telling you to run "service postgresql initdb", and I think it's a considerable step backwards that that's now buried in some unspecified log file (if indeed it is; some poking around fails to find anything at all).

Basically, I would like to know how to get systemctl the heck out of the way, for both these databases.  It's not helpful.

Comment 4 Tom Lane 2011-05-02 18:14:54 UTC
*** Bug 701362 has been marked as a duplicate of this bug. ***

Comment 5 Tom Lane 2011-05-10 21:08:11 UTC
The lack-of-message issue mentioned in comment #3 turns out to be something the systemd developers have been ignoring for awhile, see bug #622663.


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