Docker suddenly won't even start

Support
#1

image

Just rebooted unraid server and a docker image that has been running fine won’t even boot now.

Log says the following:

2024/01/12 13:42:03 172.17.0.1:2617 POST /start_stop_backup
2024/01/12 13:42:13 Failed to stop the backup job

2024/01/12 13:42:13 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:42:14 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:42:15 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:42:16 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:42:17 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:42:18 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:42:19 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:43:20 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:44:21 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:45:22 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:46:23 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:47:23 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:48:24 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:49:25 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:50:26 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:51:27 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:52:28 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:53:29 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:54:30 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:55:30 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:56:30 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:57:31 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:58:32 172.17.0.1:2614 POST /get_backup_status
2024/01/12 13:59:33 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:00:33 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:01:34 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:02:35 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:03:36 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:04:37 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:05:38 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:06:39 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:07:40 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:08:41 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:09:42 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:10:43 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:11:44 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:12:45 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:13:45 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:14:46 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:15:47 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:16:48 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:18:04 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:18:50 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:19:50 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:20:51 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:21:51 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:22:52 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:23:53 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:24:54 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:25:54 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:26:55 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:27:55 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:28:55 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:29:56 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:30:57 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:31:58 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:32:58 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:33:58 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:34:59 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:35:59 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:37:00 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:38:01 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:39:02 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:40:03 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:41:04 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:42:04 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:43:04 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:44:05 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:45:06 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:46:07 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:47:08 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:48:09 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:49:10 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:50:10 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:51:11 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:52:12 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:53:13 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:54:13 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:55:13 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:56:14 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:57:14 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:58:15 172.17.0.1:2614 POST /get_backup_status
2024/01/12 14:59:15 172.17.0.1:2614 POST /get_backup_status
2024/01/12 15:00:16 172.17.0.1:2614 POST /get_backup_status
2024/01/12 15:01:17 172.17.0.1:2614 POST /get_backup_status
2024/01/12 15:02:17 172.17.0.1:2614 POST /get_backup_status
2024/01/12 15:03:18 172.17.0.1:2614 POST /get_backup_status

Terminating pid 18....
Exiting.
#2

Well it says “server error”. Its unraid issue.

#3

So it turned out the issue was the docker won’t even start if paths passed to it don’t exist. I think that really needs to be fixed as obviously offsite storages won’t always be online and to break the whole docker because of that seems to be an over sign.

#4

This was docker behavior since day zero.

How else you want to it behave? If the mapped path does not exist — what shall be mapped in to container? Failing to start a container is a correct behavior.

If you want to workaround it — map a persistent parent directory into the container instead of the disappearing subdirectories.

This is far away from being unraid, let alone duplicacy specific issue. This is basics of using containeiized applications. You may want to ask for further clarification on docker forums.

#5

All other container still start gracefully and give useful error messages.

In this case, if I pass a parent directory that does exist to the duplicacy docker, what’s the best way of adjusting paths that I’ve already set up to match?

#6

All other containers don’t have mounts that point to missing folders. Again, this has nothing to do with duplicacy, it’s docker behavior.