Repository: Cloud-CV/EvalAI
Issue: Docker startup fails due to interactive input in seed command
Root cause: Validation Gap

### Problem
When running EvalAI using Docker, the Django container fails to start due to an `EOFError` raised from an interactive `input()` call in the seed command.

This happens because `python manage.py seed` is executed automatically during container startup in a non-interactive environment.

### Steps to Reproduce
1. Clone the EvalAI repository
2. Run `docker compose up --build`
3. Observe the Django container exit with:




### Root Cause
The seed script prompts for user input when existing database data is detected. Docker containers are non-interactive, so `input()` raises `EOFError`.

### Expected Behavior
The seed command should not require interactive input in Docker or CI environments.

### Suggested Fix
Skip database reseeding safely in non-interactive environments instead of prompting for input or crashing.


Hi @Mahendra1706 👋  
Thanks for reporting this issue — I was able to reproduce the problem locally while running EvalAI via Docker.

I’d like to work on a fix to make the `seed` command safe for non-interactive environments (Docker/CI), so that it doesn’t crash due to interactive `input()` calls and instead exits gracefully or skips reseeding when appropriate.

I’ll proceed with investigating the best approach and open a PR once ready.  
Looping in a maintainer for visibility: @RishabhJain2018 

Thanks!



Hi @5hank6 👋

Thanks a lot for looking into this and for the detailed explanation — that makes sense now.

From my side, while debugging this locally I identified that the crash happens due to the input() call inside check_database() when running python manage.py seed in a non-interactive environment (Docker/CI), which leads to an EOFError.

My initial thought was to handle this defensively by either skipping reseeding or exiting gracefully when stdin is unavailable (e.g. Docker/CI), instead of prompting the user. However, I see that your approach of explicitly making the seed command safe for non-interactive environments is cleaner and more robust.

 thanks again for taking this forward and looping in the maintainer 🙌

Thanks a lot for confirming this, Mahendra — really appreciate the detailed validation 🙌  

Glad we’re aligned on the root cause and approach for making the seed command safe in non-interactive environments.

I’m currently working on getting the CI green for the PR. Travis is failing due to some existing dependency conflicts (cfn-lint / networkx / PyYAML), which seem unrelated to the seed logic itself but block the build.

I’m trying to resolve this with minimal, targeted changes. I’ll update the PR shortly, and please let me know if you’d prefer handling the CI cleanup separately.


That sounds good — thanks for the update 👍

I agree the dependency conflicts look orthogonal to the seed logic itself, so keeping the PR focused makes sense.

If it helps, I’m happy to collaborate on investigating the CI/dependency issues alongside you. so we can get the build green without broad changes. Just let me know what would be most useful.

I was able to reproduce this issue on Windows.

When running the Django container, it exits immediately with: "**/usr/bin/env: ‘bash\r**’_**: No such file or directory**_"

This typically indicates Windows CRLF (\r\n) line endings in shell scripts. Inside the Linux container, the shebang is interpreted as "**_#!/usr/bin/env bash\r_**" , which causes exit code 127.

The container entry command points to the following scripts:

 "**docker/wait-for-it.sh**"

"**docker/dev/django/container-start.sh**"

The files and paths themselves seem to be correct, so converting these scripts to LF line endings (and/or enforcing LF for .sh files in the repo) should resolve the issue on Windows.

Sharing this in case it helps narrow down the root cause.

Just adding a data point here: the Travis failure seen on #4852 (which only enforces LF line endings via .gitattributes) matches the same Build, Test & Check Code Quality failure being tracked in #4846 across multiple unrelated PRs.

Locally, enforcing LF resolves the Windows Docker startup error (/usr/bin/env: bash\r), so the CRLF issue itself appears fixed, while the remaining blocker looks CI-level rather than PR-specific.

Thanks for pointing that out Youssef-SH.

Yes, that matches what I observed as well. The CRLF --> LF enforcement resolves the Windows-side Docker startup error (`/usr/bin/env: bash\r`) locally. The Travis failure seems consistent with the CI issue being tracked in #4846 and appears unrelated to the changes in this PR.

Happy to make any adjustments if needed.


Hi @RishabhJain2018 and maintainers 👋,

I've been testing the seed script issue locally and I understand that the crash happens due to the `input()` call in `check_database()` when running in non-interactive environments (Docker/CI), which raises an `EOFError`.

From my exploration:

* The initial setup works fine because the database is empty and `input()` is not reached.
* On subsequent runs, when data exists, the script prompts for confirmation, which fails in non-interactive contexts.
* `settings.TEST` is `False` in my setup, so the test-mode bypass does not trigger.

To handle **all scenarios** safely, a possible approach could be:

1. Detect whether the environment is interactive (`sys.stdin.isatty()`).
2. Only prompt for input in interactive terminals (normal terminal or Docker with TTY/interactive mode enabled).
3. Skip reseeding gracefully in non-interactive environments (Docker without TTY, CI).
4. Preserve `settings.TEST` behavior for automated tests.

This approach keeps the **interactive user input behavior** for users who want it (including those running Docker interactively) while preventing crashes in non-interactive contexts.

I am working local prototype implementing this logic, which avoids crashes and preserves interactivity where possible.

If this aligns with the maintainer's vision, I'd be happy to submit a PR for review. Could this issue be assigned to me?

Thanks! 🙌