Bug 752863
Summary: | katello service will return "OK" even if it all thin threads do not start correctly. | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Corey Welton <cwelton> |
Component: | API | Assignee: | Miroslav Suchý <msuchy> |
Status: | CLOSED UPSTREAM | QA Contact: | Katello QA List <katello-qa-list> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 6.0.0 | CC: | lzap, mmccune, msuchy, omaciel |
Target Milestone: | Unspecified | Keywords: | Triaged |
Target Release: | Unused | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | katello-1.1.10 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-09-19 18:15:11 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: | 754127, 758651 | ||
Bug Blocks: | 747354 |
Description
Corey Welton
2011-11-10 16:08:28 UTC
errr... 2) After an unclean shutdown, we're NOT catching such problems on startup. Investigating. This is rather feature of systemd. On Fedoras (15/16) our script actually never gets executed, because systemd already sees the instance is running. Try this: systemctl status katello.service Loaded: loaded (/etc/rc.d/init.d/katello) Active: active (running) since Tue, 15 Nov 2011 12:09:08 +0100; 3min 26s ago Process: 2297 ExecStop=/etc/rc.d/init.d/katello stop (code=exited, status=0/SUCCESS) Process: 2317 ExecStart=/etc/rc.d/init.d/katello start (code=exited, status=0/SUCCESS) Main PID: 1648 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/katello.service ├ 2328 thin server (0.0.0.0:5000) ... └ 2336 thin server (0.0.0.0:5001) kill 2336 systemctl status katello.service It still reports it is running. I guess we need to write our own systemd units for taking care of that. I am really not sure if it helps. Giving it low priority as we can live with that until V1. http://fedoraproject.org/wiki/Packaging:Systemd I have modified your init script and enhanced "status" call - now it properly checks for all PID files. On top of that I have found we are running thin with a daemon command - this is not necessary since thin already daemonize processes. I removed that. I also removed unnecessary check_permission call because thin reports error when pid is not writable. This test was because of previous server (Webrick). 7d1da2e 752863 - katello service will return "OK" on error @Corey - Can you please try it again with my patch on Fedora and RHEL? If they both give the same result, I suggest to postpone this one. Please set back to MODIFIED once you are done with the testing, thanks. I have talked to systemd guys and it seems it can't handle it. Adding dependency 754127 for this one. [root@qetello02 ~]# service katello stop Stopping server on 0.0.0.0:5000 ... ^CStopping server on 0.0.0.0:5001 ... Sending QUIT signal to process 19109 ... >> Exiting! Stopping server on 0.0.0.0:5002 ... Sending QUIT signal to process 19115 ... >> Exiting! Stopping server on 0.0.0.0:5003 ... Sending QUIT signal to process 19147 ... >> Exiting! Stopping server on 0.0.0.0:5004 ... Sending QUIT signal to process 19161 ... >> Exiting! [root@qetello02 ~]# ps ax | grep thin 26050 pts/2 R+ 0:00 grep thin [root@qetello02 ~]# service katello start Starting katello: Starting server on 0.0.0.0:5000 ... Starting server on 0.0.0.0:5001 ... Starting server on 0.0.0.0:5002 ... Starting server on 0.0.0.0:5003 ... Starting server on 0.0.0.0:5004 ... [ OK ] Okay, I was NOT able to VERIFY this one. 1) stop katello 2) occupy one port, eg. with nc -l 5001 & 3) start katello It reports OK but one instance (5001) was not started. We cannot do much anything with it. Thin returns ok in this case. Maybe we could add an explicit check for open ports before starting this, or explicit check after we start (something like pgrep)... if [ $(pgrep thin | wc -l) -eq $THIN_INSTANCES ]; then echo OK else echo FAIL fi It would be better to have some support upstream. Let's wait for them: https://github.com/macournoyer/thin/issues/93 Setting back to NEW These bugs have been resolved in upstream projects for a period of months so I'm mass-closing them as CLOSED:UPSTREAM. If this is a mistake feel free to re-open. |