Bug 714525
Summary: | RFE: systemctl could warn when asked to stop a service while the associated socket is still listening | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
Component: | systemd | Assignee: | Michal Sekletar <msekleta> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | harald, johannbg, johannbg, lpoetter, metherid, mschmidt, msekleta, notting, plautrba, scox, tmraz, wcohen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-20 19:25:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 784611 |
Description
Harald Reindl
2011-06-19 21:44:32 UTC
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! 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. |