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

When closing descriptors, set some fixed (configurable?) cap #78

Open
devgs opened this issue Oct 30, 2020 · 2 comments
Open

When closing descriptors, set some fixed (configurable?) cap #78

devgs opened this issue Oct 30, 2020 · 2 comments

Comments

@devgs
Copy link

devgs commented Oct 30, 2020

Currently, at daemonize.py#L137:

for fd in range(3, resource.getrlimit(resource.RLIMIT_NOFILE)[0]):

It's not very wise to use RLIMIT_NOFILE for this purpose. In real-world production servers this value may be as high as few tens of millions. In which case, daemonization will spam the system with useless syscalls and be delayed up to tens of seconds because of that.

It's not reasonable to attempt to close more that few thousands of descriptors. After all, daemonization, almost exclusively takes place immediately after the start of application. There's no way that a normal app is going to have this many open descriptors during that time.

@miigotu
Copy link

miigotu commented Aug 2, 2021

Is disabling closing of file descriptors altogether and managing your pre-daemonization descriptors yourself a proper way to work around this?

@devgs
Copy link
Author

devgs commented Aug 2, 2021

@miigotu As an option - definitely. But i would suggest adding an optional function parameter (callback) that should handle the closing, to override the built-in logic.

Moreover, the closing should definitely be handled by the child side of the post-fork pair. Imagine a scenario, when the pipe is created. One side (descriptor) belongs to a parent and the other side to the child (now daemon). Parent process can't close any of them before doing the fork. It's the child's responsibility to close the parent's side and vice versa. But both must do it post-fork.

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

No branches or pull requests

2 participants