xorinzor Posted January 27, 2020 Share Posted January 27, 2020 I run roughly 11 different docker containers on my Unraid (now 6.8.2) installation. Since the beginning I've always had the same issue, that the Medusa container after a reboot doesn't start, and when attempting to start it manually I get the error "no such container". To fix this, I always just go to container -> edit, edit a field so the "apply" button becomes available, and then click it. After this, the container works perfectly fine again. I also tried deleting the container and re-installing it, but the same issue keeps happening. Would appreciate some help in diagnosing this problem. Quote Link to comment
whitedwarf Posted January 27, 2020 Share Posted January 27, 2020 Not sure that will help but, as far as I have seen, deleting the container does not mean its parameters are deleted. To be sure you are on a clean basis you should ssh and delete the "appdata/Medusa" folder after deleting the container. Of course you will have to configure it again ... but hopefully for the last time. Quote Link to comment
xorinzor Posted January 27, 2020 Author Share Posted January 27, 2020 21 minutes ago, whitedwarf said: Not sure that will help but, as far as I have seen, deleting the container does not mean its parameters are deleted. To be sure you are on a clean basis you should ssh and delete the "appdata/Medusa" folder after deleting the container. Of course you will have to configure it again ... but hopefully for the last time. That's the thing I thought of at first too, but after deleting the container, and re-installing it, the configuration screen was reset completely to it's default values. No added ports, default docker network, default system paths, etc. So all that it gets from the appdata folder is the medusa app configuration, but that shouldn't have any impact on the container itself, as it's just a mounted folder. Quote Link to comment
Xaero Posted January 27, 2020 Share Posted January 27, 2020 Post the docker run command. That'll help identify the problem. Not much we can do with just guessing at it. Usually I see this with my custom network docker containers that connect to another docker as their network (I have a VPN docker, which other dockers use as their network) And the solution is also identical: edit the docker, change something and hit apply. To fix this for startup: Make the medusa container start after the container it depends on. This can be achieved by dragging it LOWER on the list in the WebUI (the order they are shown in is the order they start in) Quote Link to comment
xorinzor Posted January 27, 2020 Author Share Posted January 27, 2020 5 minutes ago, Xaero said: Post the docker run command. That'll help identify the problem. Not much we can do with just guessing at it. Usually I see this with my custom network docker containers that connect to another docker as their network (I have a VPN docker, which other dockers use as their network) And the solution is also identical: edit the docker, change something and hit apply. To fix this for startup: Make the medusa container start after the container it depends on. This can be achieved by dragging it LOWER on the list in the WebUI (the order they are shown in is the order they start in) That sounds like the same kind of setup I have. I also have 2 other docker containers on the same vpn docker-network which start before medusa, and those always start just fine. This is the run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='medusa' --net='vpn' --ip='10.10.0.5' --cpuset-cpus='0,1,4,5' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/user0/Media/Series/':'/tv':'rw' -v '/mnt/cache/Downloads/':'/downloads':'rw' -v '/mnt/disks/system_ssd/appdata/medusa':'/config':'rw' -h medusa --cap-add=NET_ADMIN 'linuxserver/medusa' ;/mnt/disks/system_ssd/docker_post_startup/medusa.sh Quote Link to comment
Xaero Posted January 27, 2020 Share Posted January 27, 2020 (edited) 2 minutes ago, xorinzor said: That sounds like the same kind of setup I have. I also have 2 other docker containers on the same vpn docker-network which start before medusa, and those always start just fine. This is the run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='medusa' --net='vpn' --ip='10.10.0.5' --cpuset-cpus='0,1,4,5' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/user0/Media/Series/':'/tv':'rw' -v '/mnt/cache/Downloads/':'/downloads':'rw' -v '/mnt/disks/system_ssd/appdata/medusa':'/config':'rw' -h medusa --cap-add=NET_ADMIN 'linuxserver/medusa' ;/mnt/disks/system_ssd/docker_post_startup/medusa.sh --net='vpn' Indeed; whatever container is defined as 'vpn' needs to be started before Medusa. If that network isn't ready medusa might be failing to start properly. If that's the case you might start it using a user script with a delay. Edited January 27, 2020 by Xaero Quote Link to comment
xorinzor Posted January 27, 2020 Author Share Posted January 27, 2020 Just now, Xaero said: --net='vpn' Indeed; whatever container is defined as 'vpn' needs to be started before Medusa. There is no container defined as 'vpn', it's a separate docker network that I created, in which I configured a docker container as the gateway. This way, I don't require any order in which to start the containers. Either way, the "gateway container" is ordered to start first, with 2 other containers starting after it, after which the medusa container is launched. So I don't think this is the cause of the problem. I have multiple docker networks configured, none of my other containers show this issue. Quote Link to comment
itimpi Posted January 27, 2020 Share Posted January 27, 2020 1 minute ago, Xaero said: --net='vpn' Indeed; whatever container is defined as 'vpn' needs to be started before Medusa. On that basis it is worth pointing out that docker start order can be changed by dragging them into order on the Dockers tab. In advanced view you can also add a delay before starting the next docket Quote Link to comment
xorinzor Posted January 27, 2020 Author Share Posted January 27, 2020 2 minutes ago, itimpi said: On that basis it is worth pointing out that docker start order can be changed by dragging them into order on the Dockers tab. In advanced view you can also add a delay before starting the next docket I am aware of that Quote Link to comment
Xaero Posted January 27, 2020 Share Posted January 27, 2020 (edited) EDIT: That wouldn't make sense. I forgot that you are getting a "No Such Container" message. Edited January 27, 2020 by Xaero Quote Link to comment
xorinzor Posted January 27, 2020 Author Share Posted January 27, 2020 (edited) 7 minutes ago, Xaero said: On a failed start attempt, is there anything in the log for the Medusa container? Perhaps its trying to reach the internet, but the VPN connection hasn't been established in the VPN container? Unfortunately not I checked the entire syslog file, but this is the only line that stands out (anything from before the reboot has wiped itself since it's loaded in RAM). Apparently the error in the log file is different then the error the WebGUI gives. The WebGUI always says "no such container", but the log file seems to say the network doesn't exist. Jan 27 16:58:13 STORAGE rc.docker: medusa: Error response from daemon: network a2603ce63d6661af7f33861e9092ad3ac52d3ed21bf5774e1632c0f00caa3275 not found Jan 27 16:58:13 STORAGE rc.docker: Error: failed to start containers: medusa Which seems odd to me, because this same "--net='vpn'" parameter is used in the 2 docker containers before it, without error. If medusa required an internet connection, the error message should be different I assume? At least we're 1 step further haha. EDIT: these are my networks. NETWORK ID NAME DRIVER SCOPE 2679778bf026 br0 macvlan local c13b7c638210 bridge bridge local 5f6a3251a135 efkstack bridge local ded1db5fe48f host host local 9600105bc546 none null local 187af992fc33 vpn bridge local 7e1e3d9bd667 webhost bridge local Edited January 27, 2020 by xorinzor Quote Link to comment
Xaero Posted January 28, 2020 Share Posted January 28, 2020 If you move the medusa container to start before the other two containers, does it work? I'm curious to know if this is a timing thing, or if the network is getting re-created over and over with a new ID each time a docker joins the network? I'm still learning docker stuff myself haha. Quote Link to comment
xorinzor Posted January 28, 2020 Author Share Posted January 28, 2020 7 hours ago, Xaero said: If you move the medusa container to start before the other two containers, does it work? I'm curious to know if this is a timing thing, or if the network is getting re-created over and over with a new ID each time a docker joins the network? I'm still learning docker stuff myself haha. the name "vpn" is just an alias that it resolves within the run command to the ID of the network. If the network were to change after the earlier 2 containers initialized I would run into the problem of those 2 not having a network connection, but they run completely fine. Took me a while to learn these things about docker too, no worries it's why I enjoy working with Unraid so much Quote Link to comment
bonienl Posted January 28, 2020 Share Posted January 28, 2020 Each time the docker service is started, it will create a new ID for each network it knows. In the script used by Unraid the containers are automatically updated for any custom (macvlan) networks, but this does not happen for user created networks (such as your VPN network). Hence the container fails to start (the message in the GUI is a bit misleading here). When you edit the container and change/undo a setting, it will force the container to update itself and learn the new network ID. Quote Link to comment
xorinzor Posted January 28, 2020 Author Share Posted January 28, 2020 (edited) 43 minutes ago, bonienl said: Each time the docker service is started, it will create a new ID for each network it knows. In the script used by Unraid the containers are automatically updated for any custom (macvlan) networks, but this does not happen for user created networks (such as your VPN network). Hence the container fails to start (the message in the GUI is a bit misleading here). When you edit the container and change/undo a setting, it will force the container to update itself and learn the new network ID. I understand that the networks and containers get new ID's, that's why they're configured using the name of the network (ie: alias) rather then ID. If this however would be the reason of the problem, not just this single container should fail to start every time, but 7 others too. Since I have quite a few containers utilizing these networks, including 2 other containers using the "vpn" network, and starting at boot just fine. Edited January 28, 2020 by xorinzor Quote Link to comment
Hans Posted April 26, 2020 Share Posted April 26, 2020 I have the same issue and I didn't realize you can just modify and apply to fix it. What I was used to do is, go to settings and disable the docker and re-enable it. This might help with your 7+ containers. I only have issues with one container that requires br0 accesses. Quote Link to comment
xorinzor Posted April 26, 2020 Author Share Posted April 26, 2020 3 hours ago, Hans said: I have the same issue and I didn't realize you can just modify and apply to fix it. What I was used to do is, go to settings and disable the docker and re-enable it. This might help with your 7+ containers. I only have issues with one container that requires br0 accesses. Disabling and re-enabling doesn't work for me, I've done that in the past for some other reasons, but this container always has had the same problem. Still unresolved, I don't believe it has anything to do with the custom networks since all of my other containers work with custom networks just fine. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.