Behavior change for docker_logs in 0.49.0

[mwhahaha]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

The 0.49.0 version of vector fails to start if docker logs are configured and the docker socket is not available. This is a change from 0.48.0 where vector would start.

1. upgrade to 0.49.0
2. configure docker_logs source on a host without docker
3. attempt to start service

It should be noted that the same configuration works on 0.48.0

Configuration

sources:
  docker_logs:
    type: docker_logs

sinks:
  dummy:
    type: console
    inputs:
      - docker_logs
    encoding:
      codec: json
    target: stdout

Version

vector 0.49.0 (x86_64-unknown-linux-gnu dc7e792 2025-08-12 13:47:08.632326804)

Debug Output

2025-08-13T14:18:52.954402Z DEBUG vector::app: Internal log rate limit configured. internal_log_rate_secs=10
2025-08-13T14:18:52.954467Z  INFO vector::app: Log level is enabled. level="trace"
2025-08-13T14:18:52.954545Z DEBUG vector::app: messaged="Building runtime." worker_threads=12
2025-08-13T14:18:52.954682Z TRACE mio::poll: registering event source with poller: token=Token(1), interests=READABLE    
2025-08-13T14:18:53.154806Z  INFO vector::app: Loading configs. paths=["/etc/vector/vector.yaml"]
2025-08-13T14:18:53.180555Z DEBUG vector::config::loading: No secret placeholder found, skipping secret resolution.
2025-08-13T14:18:53.181174Z DEBUG vector::topology::builder: Building new source. component=docker_logs
2025-08-13T14:18:53.197037Z DEBUG vector::topology::builder: Building new sink. component=dummy
2025-08-13T14:18:53.197278Z ERROR vector::topology::builder: Configuration error. error=Source "docker_logs": Socket not found: /var/run/docker.sock

Example Data

No response

Additional Context

Here is the debug output from 0.48.0 for comparison

2025-08-13T14:19:13.887099Z DEBUG vector::app: Internal log rate limit configured.
2025-08-13T14:19:13.887136Z  INFO vector::app: Log level is enabled. level="trace"
2025-08-13T14:19:13.887185Z DEBUG vector::app: messaged="Building runtime." worker_threads=12
2025-08-13T14:19:13.887310Z TRACE mio::poll: registering event source with poller: token=Token(1), interests=READABLE    
2025-08-13T14:19:13.901001Z  INFO vector::app: Loading configs. paths=["/etc/vector/vector.yaml"]
2025-08-13T14:19:13.901919Z DEBUG vector::config::loading: No secret placeholder found, skipping secret resolution.
2025-08-13T14:19:13.902296Z DEBUG vector::topology::builder: Building new source. component=docker_logs
2025-08-13T14:19:13.902678Z  INFO source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::sources::docker_logs: Capturing logs from now on. now=2025-08-13T07:19:13.902624760-07:00
2025-08-13T14:19:13.902711Z TRACE source{component_kind="source" component_id=docker_logs component_type=docker_logs}: bollard::uri: pairs: {"since":"1755094753.902624760","until":"","filters":"{\"event\":[\"start\",\"unpause\",\"die\",\"pause\"],\"type\":[\"container\"]}"}    
2025-08-13T14:19:13.902730Z TRACE source{component_kind="source" component_id=docker_logs component_type=docker_logs}: log: Internal log [pairs: {"since":"1755094753.902624760","until":"","filters":"{\"event\":[\"start\",\"unpause\",\"die\",\"pause\"],\"type\":[\"container\"]}"}] is being suppressed to avoid flooding.
2025-08-13T14:19:13.902748Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: bollard::docker: unix://2f7661722f72756e2f646f636b65722e736f636b/events?since=1755094753.902624760&until=&filters=%7B%22event%22%3A%5B%22start%22%2C%22unpause%22%2C%22die%22%2C%22pause%22%5D%2C%22type%22%3A%5B%22container%22%5D%7D    
2025-08-13T14:19:13.902791Z  INFO source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::sources::docker_logs: Listening to docker log events.
2025-08-13T14:19:13.902820Z DEBUG vector::topology::builder: Building new sink. component=dummy
2025-08-13T14:19:13.902916Z  INFO vector::topology::running: Running healthchecks.
2025-08-13T14:19:13.902929Z DEBUG vector::topology::running: Connecting changed/added component(s).
2025-08-13T14:19:13.902946Z DEBUG vector::topology::running: Configuring outputs for source. component=docker_logs
2025-08-13T14:19:13.902963Z DEBUG vector::topology::running: Configuring output for component. component=docker_logs output_id=None
2025-08-13T14:19:13.902974Z DEBUG vector::topology::running: Connecting inputs for sink. component=dummy
2025-08-13T14:19:13.902985Z DEBUG vector::topology::running: Adding component input to fanout. component=dummy fanout_id=docker_logs
2025-08-13T14:19:13.903005Z DEBUG vector::topology::running: Spawning new source. key=docker_logs
2025-08-13T14:19:13.903026Z TRACE vector::topology::running: Spawning new sink. key=dummy
2025-08-13T14:19:13.903057Z  INFO vector: Vector has started. debug="false" version="0.48.0" arch="x86_64" revision="a67e4e2 2025-06-30 18:25:45.272082383"
2025-08-13T14:19:13.903069Z  INFO vector::app: API is disabled, enable by setting `api.enabled` to `true` and use commands like `vector top`.
2025-08-13T14:19:13.903079Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::topology::builder: Source pump supervisor starting.
2025-08-13T14:19:13.903085Z DEBUG sink{component_kind="sink" component_id=dummy component_type=console}: vector::topology::builder: Sink starting.
2025-08-13T14:19:13.903131Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::topology::builder: Source pump starting.
2025-08-13T14:19:13.903088Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::topology::builder: Source starting.
2025-08-13T14:19:13.904022Z TRACE vector: Beep.
2025-08-13T14:19:13.914624Z  INFO vector::topology::builder: Healthcheck passed.
2025-08-13T14:19:13.915071Z DEBUG sink{component_kind="sink" component_id=dummy component_type=console}: vector::utilization: utilization=0.9999320205959992
2025-08-13T14:19:13.915054Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: log: Internal log [unix://2f7661722f72756e2f646f636b65722e736f636b/events?since=1755094753.902624760&until=&filters=%7B%22event%22%3A%5B%22start%22%2C%22unpause%22%2C%22die%22%2C%22pause%22%5D%2C%22type%22%3A%5B%22container%22%5D%7D] is being suppressed to avoid flooding.
2025-08-13T14:19:13.915315Z ERROR source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::sources::docker_logs: Listing currently running containers failed. error=Error in the hyper legacy client: client error (Connect)
2025-08-13T14:19:13.915341Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::topology::builder: Source finished normally.
2025-08-13T14:19:13.915352Z  INFO vector_common::shutdown: All sources have finished.
2025-08-13T14:19:13.915363Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::topology::builder: Source pump finished normally.
2025-08-13T14:19:13.915365Z  INFO vector_common::shutdown: Internal log [All sources have finished.] is being suppressed to avoid flooding.
2025-08-13T14:19:13.915399Z  INFO vector::app: All sources have finished.
2025-08-13T14:19:13.915404Z DEBUG source{component_kind="source" component_id=docker_logs component_type=docker_logs}: vector::topology::builder: Source pump supervisor task finished normally.
2025-08-13T14:19:13.915412Z  INFO vector: Vector has stopped.
2025-08-13T14:19:13.915471Z DEBUG sink{component_kind="sink" component_id=dummy component_type=console}: vector::topology::builder: Sink finished normally.

References

No response

[thomasqueirozb]

Caused by #20958
See: https://github.com/vectordotdev/vector/pull/20958/files#diff-210c52ce2a27452880fc3200132e34d6f7fbc7153b3ab191cfdd547a545a7eefR11-R12

This was introduced due to the bollard upgrade despite no API changes on our end. While this is a behavior change I don't think this is a bug per se since Vector won't properly work with the source being inaccessible.

You could always ensure docker is already up before spinning up Vector by using something like:

[Unit]
Description=My Service that needs Docker
Requires=docker.service
After=docker.service

(Assuming you're using systemd)

Is there an use case why you want vector to spin up without the docker daemon being accessible?

[mwhahaha]

In our environment Vector is used for multiple log types and docker may or may not be deployed on the target system. For simplicity it'd be nice if we could configure it and vector would pickup the logs if they become available rather than hard failing. A warning might be better than a hard failure. I'd see it similar to some other file based log service where the log dir might exist but there's nothing there unless the service is started up.

[mwhahaha]

Actually there is the unintended consequence of actually starting docker on vector restart since the socket will activate docker.

systemctl stop docker
systemctl restart vector
systemctl status docker

So it seems this is only an issue if vector is installed/configured prior to the docker package being installed. It's not great that vector triggers docker starting up but that's likely always been the case.

[pront]

A good general strategy for components that rely on background services is:

• if healthchecks are enabled and the required dependency (in this case Docker daemon) is down, then fail to start
• if healthchecks are disabled, then Vector should start and the component should attempt to reconnect (as long as Vector is up) with an exponential backoff timeout (and a max limit of e.g. 60 seconds)

In this model, it’s not advisable to rely on Vector to start the Docker daemon itself. Instead, if we think of dependencies as a graph, the ideal approach is to perform a topological sort of the services, eliminate any cycles, and enable health checks. When that’s not possible, reconnection attempts provide a practical fallback.

[pront]

@thomasqueirozb created #23608. Based on that and the discussion above, I think we can close this ticket. That said, please feel free to add further comments or reopen the issue if you think we haven’t fully addressed all concerns.