Docker never starts with run.sh
Hi.
It is my first attempt on using the autoware project. I'm running everything on Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-62-generic x86_64).
I'm following the steps to install/use autoware via the docker approach, following the the installation guide. I have docker-ce 19.03 installed and can successfully run both run docker hello-world and docker run --runtime=nvidia --rm nvidia/cuda nvidia-smi. Thus, I belive that both docker and nvidia runtime settings are ok, installed accordingly to the instructions.
However, when I proceed to start the docker, it takes 'forever' to start, as reported above.
pedro@p0server:/scratch/autoware/docker/generic$ ./run.sh
Using options:
ROS distro: melodic
Image name: autoware/autoware
Tag prefix: latest
Cuda support: on
Pre-release version: off
UID: <1014>
Launching autoware/autoware:latest-melodic-cuda
Unable to find image 'autoware/autoware:latest-melodic-cuda' locally
latest-melodic-cuda: Pulling from autoware/autoware
7ddbc47eeb70: Already exists
c1bbdc448b72: Already exists
8c3b70e39044: Already exists
45d437916d57: Already exists
2b9b01e3e432: Pulling fs layer
04fb7e096fb1: Pulling fs layer
516bdffd8ca2: Pulling fs layer
60339fb0d35d: Pulling fs layer
f443a7a7d6ca: Pulling fs layer
a8fa796f177c: Pulling fs layer
6960f5a11411: Pull complete
a9f77b2b02e4: Pull complete
cdc5942e3fe6: Pull complete
c9b7baf524c9: Pull complete
3a8eadf0d457: Pull complete
acb09b0e5e84: Pull complete
037448bf7e7f: Pull complete
7c4970c95db8: Pull complete
e3c2bd6ca232: Pull complete
ccf6832e4897: Pull complete
0b8d377ac46d: Pull complete
7a457cce8ed2: Pull complete
5c0ab1da738e: Pull complete
101bea683c7d: Pull complete
bd53215473a0: Pull complete
a09161de1216: Pull complete
765f6cfa1af2: Pull complete
b209f717e1df: Pull complete
255191677602: Pull complete
2c6aa05ac6a7: Pull complete
78619f8dffe5: Pull complete
be4812ebbd95: Pull complete
c3171763f3be: Pull complete
18e58ccbe414: Pull complete
143a621b3de1: Pull complete
Digest: sha256:f47b92e189b202e5a424fcfa21b69604333cef6edd8da30a9715b0af92da9ef3
Status: Downloaded newer image for autoware/autoware:latest-melodic-cuda
Changing autoware user ID to match your host's user ID (1014).
This operation can take a while...
It stays like this for more than an hour. Even though I could wait more, I don't think it is necessary/correct to wait for such a long time to start the docker, so I'm pretty sure there is something wrong.
Additionally, since I'm running on Ubuntu 16.04, I have also tried to run:
./run.sh -r kinetic -t 1.12.0
But, again, the image is downloaded but the script remains stuck in the "This operation can take a while..." message.
Do anyone knows what can be the cause of this and how to solve it? There is a git issue with a similar problem, but with no solution given.
Thank you.
Update:
I tried again and waited for a few hours (2 or 3 hours) and I got in the docker container. I believe the problem is on the find /home/autoware -user $DEFAULT_USER_ID -exec chown -h $USER_ID {} \; command, inside the entrypoint.sh file (which I guess is executed on the container startup). I'm running it on a server shared with more people, which are also executing their stuff, and the find command is simply computational intense. Given that, is there any alternative for this? Since I'm working remotely, sometimes there are broken pipes in ssh ...
that will certainly negatively influence performance, yes.
Is the machine you're remotely logged into equipped with an SSD or a mechanical, rotation HDD? That would significantly influence things as well.
Are you running things in a plain terminal session, or are you using something like
tmuxorscreen?If the former, I'd recommend using the latter.
Note: I'm not an autoware user, so it may be that there are way to avoid running that
findcommand altogether. Regardless, I'd really recommend using something liketmuxorscreenwhen running anything remotely.Thank you for the input. You are completely right. Using screen is more reliable to work on remote servers. I wasn't doing that yet because I just feel it's easier to use the terminal without the screen during the setup. Anyway, waiting for so long should still not happen.
Regarding the storage media, the docker containers are mounted into a HDD partition, due to the SSD size available in the server, so yes it can also be influencing on that.