| Summary: | unable to stop mysqld service | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander Dyadyun <Shurik> |
| Component: | systemd | Assignee: | Lennart Poettering <lpoetter> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | fedora, johannbg, lpoetter, metherid, mschmidt, notting, plautrba, tgl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-28 19:01:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Alexander Dyadyun
2011-04-28 07:45:05 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 ~]$ *** This bug has been marked as a duplicate of bug 699114 *** 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.
*** Bug 701362 has been marked as a duplicate of this bug. *** 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. |