Ticket #709 (closed defect: fixed)
1.1.0 doesn't shutdown when you ^C from a non-daemonized bcfg2-server instance.
Reported by: | Travis Campbell <[email protected]…> | Owned by: | solj |
---|---|---|---|
Priority: | major | Milestone: | Bcfg2 1.1.0 Release |
Component: | bcfg2-server | Version: | 1.0 |
Keywords: | Cc: | [email protected]…, [email protected]… |
Description
I just loaded bcfg2-server on a new box and whenever I run it in interactive mode (eg, don't daemonize and disassociate from the terminal), the bcfg2-server process refuses to die off after I hit Control-C. The last entry I see from the verbose output is:
Handled 5 events in 0.001s serve_forever() [stop] server_close()
and it hangs forever after this. I have to send a sigquit in order for it to now shutdown at this point.
Attachments
Change History
comment:2 Changed 13 years ago by https://www.google.com/accounts/o8/id?id=AItOawkTXV0x-NJtj3FJIUxtXA1nvkZpg-8kfsU
- Cc [email protected]… added
- Resolution fixed deleted
- Status changed from closed to reopened
- Component changed from bcfg2-client to bcfg2-server
This is still happening on CentOS 5 with Python 2.4 for me. Specifically using the most recent python-2.4.3-27.el5 RPM. What else should I provide to help in debugging?
comment:3 Changed 13 years ago by solj
- Milestone changed from Bcfg2 1.0.0 Release to Bcfg2 1.1.0 Release
comment:4 Changed 13 years ago by solj
- Cc [email protected]… added
- Owner changed from desai to solj
- Status changed from reopened to accepted
I'm still seeing this as well.
comment:5 Changed 13 years ago by solj
- Summary changed from 1.0pre5 doesn't shutdown when you ^C from a non-daemonized bcfg2-server instance. to 1.1.0 doesn't shutdown when you ^C from a non-daemonized bcfg2-server instance.
comment:6 Changed 13 years ago by laszlo
- Status changed from accepted to closed
- Resolution set to fixed
This isn't really limited to a non-daemonized instance. Sending sigterm to any running bcfg2-server process shows the same behavior. I would guess that the init scripts are hiding this. When the process tries to exit the fam worker thread is left running and never dies. If you touch any file in the repository "Handled 204 events in 2.173s" messages are still generated. To fix this I added a threading.Event object to Core.py so any worker thread can be signaled to stop. Also a timeout had to be added to the famfd select so this event can be reached.
Resolved in revision [49006f7886cb9f38a2b7cacd7b7c4ff32934c2b6] (SVN r5863).
comment:7 Changed 13 years ago by solj
- Cc [email protected]… added; [email protected]… removed
- Status changed from closed to reopened
- Resolution fixed deleted
Looks like this is still happening as of 1.1.0rc2 on lucid (need to check on centos).
comment:8 Changed 13 years ago by laszlo
- Status changed from reopened to closed
- Resolution set to fixed
Resolved again in revision [ab3452d3bebd31eba32bb831f7bae8de0467631e] (SVN r5925)
Fixed in [a434cd446c015980dad5ff97ac5ae33e007a5bb3] (SVN r5472)