-
Notifications
You must be signed in to change notification settings - Fork 111
json: cannot unmarshal object into Go value of type string #53
Comments
Same here |
I have no Go experience but some simple debugging suggests that every call to dockerClient is returning this json error. |
+1 for this bug |
Here the same. There must be some call in go language function that can't read correctly a formatted text exchanging data, but this is just a generic attempt to describe. |
Got this bug too. |
Doesn't fix the issue at hand, but just sharing that this fork's build worked for me: |
@darkvertex Please share the fix. Thanks. |
I can dig up the executable from my server, but maybe it would be best if @subdavis shared it themselves. (The repo disappeared. Can you share what you had fixed in your fork, @subdavis?) Sadly I don't believe I cloned the fork, so best I can do is give you the 64bit Linux build executable that is working for me. |
Thanks, it's not necessary, working forks exist. |
I deleted my fork, sorry. FWIW (and sorry for the somewhat off topic rant) systemd-docker is kind of a bad idea in general and I wouldn't recommend anyone use it. Docker (the daemon service) provides all of the same features as systemd, and they're much easier to use with docker-compose (for dependency management) and restart policies. I used to tell people that I used There's nothing wrong with this project as a neat proof of concept. It's just that the concept isn't good or practical, and you shouldn't use it in any real environment. I expect that most users of this software are, like I was, caught in a local maximum, and used this because it sorta-worked just well enough to prevent me from trying other approaches. Don't be like me. Just use docker-compose. |
@subdavis I'm not an expert on docker-compose, but I have spent quite a lot of frustrating time fighting the lack of proper dependency management. I certainly would not call it a "service manager"! There is no way to do proper dependency control in docker-compose. In particular, no way to create subsystem trees with dependency rules specified in docker-compose. Just to take a simple example from a server I am currently working on... There are three services: web front-end, nextcloud service, roundcube service. I need to be able to start and stop services, make changes (e.g. resource assignments) and restart services, etc. Each service is specified in a separate docker-compose file (each quite complex - with multiple containers, volumes, etc). I want to be able to change one of the .yml files and tell docker-compose to reestablish the modified configuration - taking into account, for example, whether it needs to restart all three services (which could be 10 in a larger deployment!) or just one or two. I want to be able to add a new service, without having to restart all the others. Etc. Systemd can do that sort of dependency management - which is why it is a service manager but docker-compose is not. |
Yep. docker-compose is smart and it does all of that. Try combining all your docker-compose files (or just specifying all of them with
yeah, it does that too. You can even change the replica counts of services (go from 4 to 8) and compose won't change any more than it has to. This is sorta exactly what I mean. People who are very familiar with systemd as an offering and not very familiar with docker-compose (like I was!) will assume that nothing can do with systemd can do. Spending some time with compose will really be an eye-opener. |
Thanks @subdavis. I will do some experimentation but I am not convinced your proposal will work. I need the docker-compose files separate because each service has its own directory tree, and are maintained separately. If I combine them (I presume using -f is equivalent to appending the files into one giant file) I am afraid I risk losing the constraints that prevent one service from reading files owned by another, for example. Also, I need to be able to (say) start all three services but later take down (say) nextcloud for maintenance. I would expect a service manager to have some way to say "stop nextcloud", which would work out what subsystems survive and what have to be stopped and would remember that the current state of the service is "stopped". Are you saying the way to do that would be to reissue the docker-compose up command leaving the -f for the nextcloud file off? I see what you mean but it is quite clunky, particularly if the operator responsible for something else needs to shutdown another subsystem and doesn't know nextcloud is also currently shutdown. Not what I would expect from a service manager - I don't think it can be called a manager if it is stateless. But thanks for the ideas - I will look into it further. For now, my systemd-driven management works "well enough". |
You guys may also wanna consider podman as a runtime instead of Docker, as it can work with almost the same API, but integrates well with systemd without hacks:
podman does not require a daemon and runs well rootless, and because it's daemon free, the process will run directly under systemd's control, without a hack necessary like systemd-docker. Most of the flags you know from "docker run" work the same in "podman run"; you'd be surprised how easy it is to port over. |
I get this error trying to run this script
The text was updated successfully, but these errors were encountered: