Ask Your Question

Docker never starts with

asked 2020-01-31 17:08:53 -0500

pedroexe gravatar image

updated 2020-02-01 07:53:03 -0500


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$ ./ 
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: ./ -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 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 ... (more)

edit retag flag offensive close merge delete


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.

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.

Since I'm working remotely, sometimes there are broken pipes in ssh connections and I'd like to regain access to autoware without having to wait for so long.

Are you running things in a plain terminal session, or are you using something like tmux or screen?

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 find command altogether. Regardless, I'd really recommend using something like tmux or screen when running anything remotely.

gvdhoorn gravatar image gvdhoorn  ( 2020-02-02 10:53:24 -0500 )edit

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.

pedroexe gravatar image pedroexe  ( 2020-02-03 07:24:05 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-02-03 02:53:53 -0500

sgermanserrano gravatar image

@pedroexe have you tried skipping the UID modification step? you can add the -s flag to the so: ./ -s

edit flag offensive delete link more


Just tried that now and the docker enters immediately, which is nice. However, I have to use 'sudo' to create/delete/edit data on the shared_dir folder (guess that is what the UID modifications try to avoid). I'll base myself on this and try a few things out, and report if I get any better than this. Thank you!

pedroexe gravatar image pedroexe  ( 2020-02-03 07:33:18 -0500 )edit

you can change the owner of the shared_dir folder once inside the container to the docker user, though you'll likely need to change it again if accessing the shared_dir folder from outside the container

sgermanserrano gravatar image sgermanserrano  ( 2020-02-03 08:25:01 -0500 )edit

I solved the issue by using the --base-only flag. I would need that anyway if I want to modify the source code and keeping it outside the docker container (which I want to). As a consequence the waiting time issue no longer exists. I could properly build autoware from the source, from inside the docker container through this way.

pedroexe gravatar image pedroexe  ( 2020-02-04 08:24:50 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2020-01-31 17:08:53 -0500

Seen: 103 times

Last updated: Feb 03