Change:
Describe the bug The docker-containers systemd services set strings for systemd options that can accept a list, like ExecStopPost and ExecStartPre: In my case I'd like to append an unrelated poststop task (a sqlite vacuum). If the options were set to lists I could just have my command merged, but because they're strings I need to mkForce and copy in the upstream commands. To Reproduce Create a config like: This results in an error: " has conflicting definitions". Expected behavior Multiple poststop declarations in the resulting unit, like what happens with Additional context This is vaguely related to , which also has to do with making more flexible. Metadata system: host os: multi-user?: sandbox: version: channels(simon): nixpkgs: Maintainer information:
I believe 's attributes get put into the unit file verbatim. This would also be a systemd.services issue, not a Docker one. Have you tried
I'm not sure it's a systemd issue: it already seems to support using lists, but docker-containers doesn't make use of them. doesn't seem to help. It results in being set as well, so causes the same error. To clarify, I'm proposing something like this: That would let docker-containers users who want to append other tasks avoid copying in the upstream config and overriding it:
I stumbled across this issue when trying to add something to . You are right about not being useful, but you solution requires a change in the systemd definition (where I do not know whether it might break something). It also makes the section less of a direct mapping between the unit file and the option. In my opinion, the correct solution would be to move the values for to the mergable options . Note that this fix should not interact with the two other proposed changes and
Unfortunately, it is not universal advice, as it won't work if there is already defined.
is defined for all containers that are created with , due to In my opinion, the value for should be moved to and to . These options allow composing. I'll prepare a pull request to fix this when I have a bit of time (I think it will be ready in ~4-5 hours).

Discussion:
wantedBy = [] ++ optional (container.autoStart) "multi-user.target"; after = [ "docker.service" "docker.socket" ] ++ mkAfter; requires = after; <ins> path = [ pkgs.docker ]; preStart = '' docker rm -f ${name} || true ${optionalString (container.imageFile != null) '' docker load -i ${container.imageFile} ''} ''; postStop = "docker rm -f ${name} || true"; </ins> serviceConfig = { ExecStart = concatStringsSep " n  " ([ "${pkgs.docker}/bin/docker run"

++ map escapeShellArg container.cmd ); <del> ExecStartPre = ["-${pkgs.docker}/bin/docker rm -f ${name}"] ++ (optional (container.imageFile != null) "${pkgs.docker}/bin/docker load -i ${container.imageFile}"); ExecStop = ''${pkgs.bash}/bin/sh -c "[ $SERVICE_RESULT = success ] || ${pkgs.docker}/bin/docker stop ${name}"''; ExecStopPost = "-${pkgs.docker}/bin/docker rm -f ${name}"; </del> <ins> ExecStop = ''${pkgs.bash}/bin/sh -c "[ $SERVICE_RESULT = success ] || docker stop ${name}"''; </ins> ### There is no generalized way of supporting `reload` for docker ### containers. Some containers may respond well to SIGHUP sent to their