json: cannot unmarshal object into Go value of type string

[kgrtr]

I get this error trying to run this script

/usr/local/bin/systemd-docker run --rm --name mycontainer

docker info
lient:
 Debug Mode: false

Server:
 Containers: 7
  Running: 1
  Paused: 0
  Stopped: 6
 Images: 18
 Server Version: 19.03.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b34a5c8af56e510852c35414db4c1f4fa6172339
 runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
 init version: fec3683
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.3.0-7625-generic
 Operating System: Ubuntu 18.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 31.22GiB
 Name: #####
 ID: ######
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

[kenthinson]

Same here

[GrahamCobb]

I have no Go experience but some simple debugging suggests that every call to dockerClient is returning this json error.

[resetsa]

+1 for this bug

[Pesach85]

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.

[darkvertex]

Got this bug too.

[darkvertex]

Doesn't fix the issue at hand, but just sharing that this fork's build worked for me:
https://github.com/subdavis/systemd-docker/releases/tag/1.0.0

[torsten-liermann]

@darkvertex Please share the fix. Thanks.

[darkvertex]

@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.

[torsten-liermann]

Thanks, it's not necessary, working forks exist.

[subdavis]

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 systemd-docker because docker was not a real, reliable service manager. I was wrong, and it is. If you need to integrate some dependencies on external systemd resources, just make those dependencies of the docker daemon and not individual containers. If you need systemd resources to depend on docker containers, it's worth your time to find a way to just not do that. docker-compose has much more powerful features for determining the status of a container service, like health checks that can send http requests on custom intervals. systemd can just be like "is the process still running? Guess it's fine...."

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.

[GrahamCobb]

@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.

[subdavis]

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.

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 'f) and bringing the stack up. Now just change 1, and run docker-compsoe up -d again. Only the changed one will update.

I want to be able to add a new service, without having to restart all the others. Etc.

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.

[GrahamCobb]

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".

[darkvertex]

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:

• https://www.tutorialworks.com/podman-systemd/
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/running_containers_as_systemd_services_with_podman

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.