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

If you are running in k8s and the process stops after authentication with the CPU reaching 100%, add this line to your k8s yaml. #401

Open
canweed opened this issue Feb 23, 2024 · 3 comments

Comments

@canweed
Copy link

canweed commented Feb 23, 2024

command: ["/bin/sh", "-c", "ulimit -n 65535 && exec /entrypoint"]

@Thorndike
Copy link

Nice! Before that I could not log in to the sftp server due to timeouts

@dmbonsall
Copy link

command: ["/bin/sh", "-c", "ulimit -n 65535 && exec /entrypoint"]

@canweed, thanks for this fix! I had the exact same problem of the process hanging in Kubernetes with the CPU stuck at 100% right after authentication. Do you happen to know why this is a problem in Kubernetes only? I have no issue running in docker-on-mac as a standalone container, and was even able to run this with no issues for several weeks on a real Kubernetes cluster until it started hanging sometime last week. Is this something that could be fixed in the image?

@canweed
Copy link
Author

canweed commented Apr 12, 2024

command: ["/bin/sh", "-c", "ulimit -n 65535 && exec /entrypoint"]

@canweed, thanks for this fix! I had the exact same problem of the process hanging in Kubernetes with the CPU stuck at 100% right after authentication. Do you happen to know why this is a problem in Kubernetes only? I have no issue running in docker-on-mac as a standalone container, and was even able to run this with no issues for several weeks on a real Kubernetes cluster until it started hanging sometime last week. Is this something that could be fixed in the image?

I want to clarify first that atmoz/sftp is not at fault. I also looked into atmoz/sftp and what it does is simply start from "FROM debian:bullseye" or "FROM alpine:latest," then install openssh-server, and configure sshd_config with a shell script.

The problem occurs in the following situation:
After entering the terminal, when you execute the command ulimit -n, it returns:

ulimit -n
1073741816

This very large value seems to be the issue.

This is a problem not only in Kubernetes but also in Docker on Rocky Linux 9.2. In Docker, the issue can be resolved by setting the option --ulimit nofile=65536:65536. However, since there is no way to set this option in Kubernetes, the

command ["/bin/sh", "-c", "ulimit -n 65535 && exec /entrypoint"]

is used to intercept the entrypoint and arbitrarily run ulimit -n 65535.

Therefore, resolving this in the image is straightforward. You just need to copy the original entrypoint from:
https://github.com/atmoz/sftp/blob/master/files/entrypoint
Add ulimit -n 65535 at the top of this script, and use it in your Dockerfile.

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

3 participants