Docker restart on CLI?

Currently reading
Docker restart on CLI?

196
36
NAS
DS920+, DS918+, DS214+, DS211j
Operating system
  1. Linux
  2. Windows
Mobile operating system
  1. Android
  2. iOS
Anybody knows how to restart docker from shell? Not the containers but the package itself.

And next question: anybody knows where I can find daemon.json that is loaded by the docker package or when not existing already where I've to create this file for docker?
 
I was looking exactly the same but "synoservice" doesn't look to be command that exist on my Synology .. Am I missing something there?
 
I was looking exactly the same but "synoservice" doesn't look to be command that exist on my Synology .. Am I missing something there?
If you are on dsm7 command is different. Examples:

Code:
usage: synopkgctl <command> [...]

command:
    enable <package>
    disable <package>
    setup <package>
    start <package>
    stop <package>
    teardown <package>
    check-startable <package>
    
systemctl restart pkgctl-WebStation
systemctl restart nginx
 
synopkgctl stop Docker stopped working for me months ago (around DSM 7.1 maybe?), instead I get this error:

Code:
Failed to load info [0x0000 (null):0]

I'm not sure it should list docker, put I noticed that synopkg list --name doesn't include docker in the results, even though Docker is definitely running on my DS920+

It was convenient to be able to restart the entire docker daemon as I have a couple containers that sometimes turn into unresponsive but unkillable zombies.
 
Last edited:
Try sudo systemctl restart pkg-Docker-dockerd

Update: with Container Manager it is sudo systemctl restart pkg-ContainerManager-dockerd

If the service should ever change its name, this command should help to identify the new name: systemctl list-units --type=service --all | grep -i docker
 
It was convenient to be able to restart the entire docker daemon as I have a couple containers that sometimes turn into unresponsive but unkillable zombies.
You should fix the images maintained by you, and raise an issue in the github repository for images of other maintainers.

See Dockerfile reference for differences between the shell form and exec form.
The shell form implicitly wraps the command with /bin/sh or /bin/bash. Some image maintainers explicitly use sh or bash in their ENTRYPOINT and/or CMD, or use the exec form to run a shell script, but don't hand over pid1 to the main process. As a result the SIGTERM signal does not reach the main process, and it can not be gracefully stopped. Some processes require a different signal for termination - it should be described in the documentation of the application/service.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

I am actually not sure, if depends_on ever played any role after the first deployment at all. Usually...
Replies
1
Views
1,405
That looks like it. You can run the task manually to test that it has worked: check in Docker to see the...
Replies
3
Views
6,669
Well IO parameters are not the best in htop. You will get better results with...
Replies
4
Views
8,443
I can’t find any option to restore just the settings. 1710356648 Phew, managed to fix it. Within the...
Replies
4
Views
390
Good to hear. Deluge has not been updated for almost two years now as an app, nevertheless. But it gives...
Replies
12
Views
960
  • Question
Open an issue on that GitHub page. The developers will be glad to assist. OP has posted two threads on...
Replies
5
Views
963
I'm happy with email notifications but in v0.3.3 of dockcheck the author added apprise notifications...
Replies
4
Views
1,042

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top