Arch Linux User Repository

Thank you @WhyNotHugo. I was thinking about reporting to Moby but I was not sure if it was only on my side or global problem for everyone :)

Hmmm... interesting finds.

I've run a single docker container: docker run --rm -it node:12 bash, and then systemctl --user stop docker.service. The container is stopped immediately, but docker takes a while to stop (20s in my case, and I'm using an override to force it to stop in 20s -- so it basically seems that it does not exit).

It seems that, if containers are running, docker stops them immediately, but docker itself does not exist quickly.

It also seems that if I stop docker, I cannot restart it without rebooting -- it seems to leave somthing in a broken state.

I'm reporting this upstream, since it doesn't seem like a packaging error: https://github.com/moby/moby/issues/41944

@WhyNotHugo you're right. If i stop every container manually before stopping service it works... But I don't understand why docker won't stop if there is running container?

PS: I've only one container launch, and it took way less than 2mins to stop. I mean is not related to time to stop the container.

PS2: and stop with --now on docker.socket does not help. Only stopping every containers works but it's a bit problematic

PS3: even with only and simplest container running docker run -d nginx. That stucks on stop.

If you merely start docker, but start no containers, does it also take too long to shut down?

I'm asking this since I want to understand if the issue is in stopping the daemon itself, or if the daemon takes too long to stop containers.

@WhyNotHugo TimeoutStopSec is not real a solution is just masking the problem. If I'm not able to find something more reliable, I may switch to that.

(I don't have my linux box atm to test), but I'll try to edit both systemd units to add Before & After. To force stoping docker.socket before docker.service. It may be work.

Oh, I've also been having long waits when powering off, but systemd did not clarify which service was holding it back.

Maybe try systemctl --user edit docker.service, and adding:

[Service]
TimeoutStopSec=20

@t3hmrman yes I'm not using sudo (just forgot), I just said I'm not touching DOCKER_HOST so I can't help you about your problem with DOCKER_HOST.

Ok but the problem with interactive --now, is that it can't be used when poweroff computer. Today, my arch took more than >2mins to shutdown because is waiting for user's systemd service to be stopped and since docker-rootless is hanging, he waits the 2mins timeout... I've to find something to be more declarative :)

@kakawait Maybe I didn't understand -- if you're using rootless docker, why would you use sudo?

I didn't customize the docker.socket unit file -- this was only when trying to shut down the systemd user-level docker service, something like this:

systemd --user stop docker (which can hang)

systemd -- user stop --now docker.socket (which cleared the hang for me IIRC)

There's a big difference between the docker unit available at the system level and the one available at the user level -- systemd stop docker !== systemd --user stop docker

[EDIT] - I fixed my issue with the ENV, it was indeed .bashrc and my issue was that I launched startx from a shell that had DOCKER_HOST set (so every shell created there-in was inheriting the variable from the initial shell, despite .bashrc being updated to remove the variable).

@t3hmrman thus you've customized the docker.socket systemd unit file? To add --now?

Otherwise no issue with the env but to be honest I always let it set. When I want to use non rootless docker I'm using sudo