Binaries not installed
Opened this issue · 5 comments
The following binaries could be created - text file busy?
Step 4 from 7: Installing binaries
cp: cannot create regular file ‘/var/packages/Docker/target/usr/bin/containerd’: Text file busy
cp: cannot create regular file ‘/var/packages/Docker/target/usr/bin/containerd-shim’: Text file busy
cp: cannot create regular file ‘/var/packages/Docker/target/usr/bin/docker’: Text file busy
cp: cannot create regular file ‘/var/packages/Docker/target/usr/bin/docker-init’: Text file busy
cp: cannot create regular file ‘/var/packages/Docker/target/usr/bin/docker-proxy’: Text file busy
cp: cannot create regular file ‘/var/packages/Docker/target/usr/bin/dockerd’: Text file busy
Step 5 from 7: Configuring log driver
Step 6 from 7: Enabling IP forwarding
Step 7 from 7: Starting Docker service
By the looks of it, the Docker binaries seem to be locked by another process. Normally the script stops the currently running Docker daemon before attempting to copy the new binaries. Would you mind sharing the full logs? And what are the results if you list the currently running Docker processes, e.g. docker ps? Perhaps the comments in issue #19 are helpful too.
I do not think so. I get the error that docker daemon could not be stopped. I have checked all the containers and stopped them manually. Is there a way to stop docker with terminal command before I run your script cuz it does not appear to be stopping the docker service
Step 1 from 7: Stopping Docker service
ERROR: Could not stop Docker daemon
admin@FarberSynology:/volume1/docker/synology-docker$
I am running this from /volume1/docker/synology-docker and use that as the same PATH. I assume that is correct? or do I need to use just /volume1/docker as the PATH. I am in directory /volume1/docker/synology-docker
I see, that part was missing from your log file. :-) The script invokes synoservicectl --stop pkgctl-Docker to stop the Docker daemon from running. This is Synology's way to control daemons and/or DSM packages. I've seen similar errors in cases where certain containers prevent a proper shutdown. Home Assistant is a well-known example (see #19). I'll add a new issue to implement a new flag to stop the containers prior to calling synoservicectl.
I'm a bit surprised the script continued to run when step 1 from 7 was unsuccessful. What was the exact command you used? And what were the full logs?
The path doesn't really matter. It's helpful to use a location you can easily remember in case you'd like to rerun the script, or would like to restore backups. You could add it to your $PATH environment variable, so you wouldn't need to call ./syno_docker_update.sh but could simply use syno_docker_update.sh.
I've just hit the same issue. And I'm running hass.io (HomeAssistant).
When I try to stop docker service via web gui then it says that hass.io depends on it.
I guess you should try to list docker dependencies and first stop them one by one and then proceed to stopping docker.
Anyway after some messing around I was able to update my docker but now it fails to start any container with:
Start container hassio_cli failed: {"message":"failed to initialize logging driver: failed to get logging factory: logger: no log driver named 'db' is registered: error looking up logging plugin db: plugin "db" not found"}.