Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Daemonize.start() shouldn't exit on failures prior to fork. #38

Open
rthille opened this issue Jan 18, 2016 · 4 comments
Open

Daemonize.start() shouldn't exit on failures prior to fork. #38

rthille opened this issue Jan 18, 2016 · 4 comments
Assignees
Milestone

Comments

@rthille
Copy link

rthille commented Jan 18, 2016

When a script tries to daemonize to perform a long running action, it should have the chance to handle errors via exceptions prior to the forking of the child.
Currently if there is already a daemon running so the parent can't get a lock on the pid file Daemonize.start() just exits. As an option at least it should just raise an exception which can be more gracefully handled in the main script.

@thesharp
Copy link
Owner

Hi @rthille

We've decided that we will raise exceptions on every error, instead of exiting silently (or sometimes printing something to the logger). This will be implemented in the nearest future. This issues will be updated with the progress.

As for now, to mitigate your issue, you can try to catch SystemExit.

@thesharp thesharp added this to the 2.5 milestone Jan 19, 2016
@thesharp thesharp self-assigned this Jan 19, 2016
@rthille
Copy link
Author

rthille commented Jan 20, 2016

I'm working on a pull-request for this. Hope to have it working with tests today...

@RealOrangeOne
Copy link
Contributor

I realise this is almost 3 years ago, but did this ever happen? It looks like the current version still terminates the application when something goes wrong, or once the parent has spawned the child, which feels very much incorrect! It also makes the library impossible to write unit tests for, as it keeps terminating mid-way through the tests.

@rthille
Copy link
Author

rthille commented Dec 12, 2018

I had working changes, but they were done at a previous company and I never sought authorization to release the change since @thesharp said the project had a different approach for a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants