You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
service --log-opt only works if you also specify --log-driver #8745
If you run docker service update myservice --log-opt mode=blocking then it appears to run successfully but doesn't actually do anything. In order to get it to set the log options, you also have to include the --log-driver flag in the same command.
Hm.. alright; so this looks to be a combination of something that's by design, and (what I think is) a bug in the docker service update logic; docker service create and update should follow slightly different logic (and I think they currently use the same).
expected: setting log-opt for a service that does not have a logging-driver configured isn't supported
reason for this is Docker ignores --log-opt (1.12.6) moby/moby#31515 (comment) that in a swarm setup, all instances of a service should use the same configuration (including logging-driver), so when specifying options, they must be accompanied with the driver
t.b.d.: creating a service with a log-opt set, but no logging driver silently ignores the option
should it produce an error? a warning?
bug: setting log-opt for a service that has a logging driver configured (when created), but without specifying that driver during update is silently ignored.
when updating a service, the CLI should take the existing logging-driver, and update the options
Taking a full example;
docker service create --log-driver=json-file --log-opt max-file=5 --name loggie nginx:alpine
docker service inspect --format='{{json .Spec.TaskTemplate.LogDriver}}' loggie
{"Name":"json-file","Options":{"max-file":"5"}}
Updating without logging-driver set doesn't take effect. IMO this should work, given that the service already had a logging-driver configured. It should still fail (or warn) if no logging-driver was configured yet on the service.
docker service update --log-opt max-file=15 loggie
docker service inspect --format='{{json .Spec.TaskTemplate.LogDriver}}' loggie
{"Name":"json-file","Options":{"max-file":"5"}}
Updating with a logging driver specified does;
docker service update --log-driver=json-file --log-opt max-file=15 loggie
docker service inspect --format='{{json .Spec.TaskTemplate.LogDriver}}' loggie
{"Name":"json-file","Options":{"max-file":"15"}}
So, I agree that we should document this (or at least make sure that any example we have does use the right combination). This bug doesn't look critical (and there's a workaround), so likely won't find its way back in all older releases (e.g. likely won't be fixed in Docker Enterprise 17.06), so having this documented would be useful even if it might be fixed in a future update.
I'll copy the information here to the docker/cli issue tracker (where I think the bug is), and will post a link to that issue here.
There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.
Prevent issues from auto-closing with a /lifecycle frozen comment.
Activity
paigehargrave commentedon Jun 1, 2019
@thaJeztah Not sure if there's still an issue here (per moby/moby#31515 (comment)) - can you PTAL when you have a free moment (har har). Thanks!
thaJeztah commentedon Jun 12, 2019
Thanks @Tomcat-Engineering (and thanks for the ping @paigehargrave)
Hm.. alright; so this looks to be a combination of something that's by design, and (what I think is) a bug in the
docker service updatelogic;docker service createandupdateshould follow slightly different logic (and I think they currently use the same).log-optfor a service that does not have a logging-driver configured isn't supportedlog-optfor a service that has a logging driver configured (when created), but without specifying that driver during update is silently ignored.Taking a full example;
Updating without logging-driver set doesn't take effect. IMO this should work, given that the service already had a logging-driver configured. It should still fail (or warn) if no logging-driver was configured yet on the service.
Updating with a logging driver specified does;
So, I agree that we should document this (or at least make sure that any example we have does use the right combination). This bug doesn't look critical (and there's a workaround), so likely won't find its way back in all older releases (e.g. likely won't be fixed in Docker Enterprise 17.06), so having this documented would be useful even if it might be fixed in a future update.
I'll copy the information here to the docker/cli issue tracker (where I think the bug is), and will post a link to that issue here.
thaJeztah commentedon Jun 12, 2019
opened docker/cli#1942
docker-robott commentedon Nov 30, 2022
There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a
/remove-lifecycle stalecomment.If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.
Prevent issues from auto-closing with a
/lifecycle frozencomment./lifecycle stale
docker-robott commentedon Jan 13, 2023
Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
/lifecycle locked