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

timeout: unrecognized option: t #111

Open
arrase opened this issue Sep 25, 2019 · 8 comments
Open

timeout: unrecognized option: t #111

arrase opened this issue Sep 25, 2019 · 8 comments
Assignees

Comments

@arrase
Copy link

arrase commented Sep 25, 2019

timeout: unrecognized option: t
BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

Usage: timeout [-s SIG] SECS PROG ARGS

Runs PROG. Sends SIG to it if it is not gone in SECS seconds.
Default SIG: TERM.
wait-for-it.sh: timeout occurred after waiting 15 seconds for 35.222.48.152:5432
no change

@h4wkmoon
Copy link

I'm this issue as well.
For fresh install, it is a bit anoying as the db is not intialized at all !

@digaetan
Copy link

I´m facing same issue...any idea how to fix it?

@inluxc
Copy link

inluxc commented Feb 6, 2020

Me too.. in AWS ECS component

@DzmitryHumianiuk
Copy link
Member

@pbortnik ^

@pbortnik
Copy link
Collaborator

Hi colleagues,
I suppose, that it need to be clarify about these services.
The service 'db-scripts' (older name 'migration') is responsible for database schema changes. So, it makes some changes only while first running. It executes default scripts. All next executions of the service show 'no changes' until the new script will be released.
So, if database is up and running, please check if it has any tables inside 'reportportal' such as 'project', 'launch' etc. If not, try to redeploy reportportal from the scratch.
The guide how to do it here

@dagansandler
Copy link

@pbortnik The issue isn't "no changes" output. It's the "timeout: unrecognized option: t" which is printed regardless. There's some issue in one of the scripts, not sure where.

@dagansandler
Copy link

relates to this I believe: vishnubob/wait-for-it#71

This exists on docker tag 5.0.0, not sure what's the base image for later tags and if the issue is there too.

seems like the migrations are running properly but it spams the log and makes you wonder if it isn't missing anything in the migrations.

@miracle8484
Copy link
Contributor

Hello, in case if issue reproduced on the latest version of migration, could you provide please detailed information (version of migration, basic state of db, and logs)?

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

8 participants