What should I do if plugin installation exceeds 120 seconds and causes the installation to fail?

[jiangpeng663]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

What should I do if plugin installation exceeds 120 seconds and causes the installation to fail? failed to launch plugin: failed to install dependencies: failed to install dependencies: signal: killed, output: DEBUG uv 0.9.26 DEBUG Acquired shared lock for /root/.cache/uv DEBUG Found project root: /app/storage/cwd/langgenius/paddleocr-0.2.2@99a900292e7992904bd419ccf10ca8578771b0b1d669cef38b4c7fb21bfe9af1 DEBUG No workspace root found, using project root DEBUG Acquired exclusive lock for /app/storage/cwd/langgenius/paddleocr-0.2.2@99a900292e7992904bd419ccf10ca8578771b0b1d669cef38b4c7fb21bfe9af1 DE...85a572e4806dc58bf1ddf651108ae8b97d5f3ebe1a244/tiktoken-0.8.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl DEBUG Sending fresh GET request for: https://files.pythonhosted.org/packages/26/32/e0e3a859136e95c85a572e4806dc58bf1ddf651108ae8b97d5f3ebe1a244/tiktoken-0.8.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl Downloading gevent (2.0MiB) Downloading pydantic-core (2.0MiB) Downloading tiktoken (1.1MiB) init process exited due to no activity for 120 seconds failed to init environment

2. Additional context or comments

No response

[dosubot[bot]]

This is a commonly reported issue where the plugin daemon's dependency download takes too long and hits the 120-second inactivity timeout. Here are the fixes, in order of effectiveness:

1. Increase the timeout and configure a PyPI mirror — add these environment variables to the plugin_daemon service in your docker-compose.yaml [1]:

plugin_daemon:
  environment:
    PYTHON_ENV_INIT_TIMEOUT: 320
    UV_HTTP_TIMEOUT: 120s
    UV_INDEX_URL: https://pypi.tuna.tsinghua.edu.cn/simple
    UV_DEFAULT_INDEX: https://pypi.tuna.tsinghua.edu.cn/simple

The paddleocr plugin has large dependencies (numpy, gevent, tiktoken, pydantic-core, etc.), so a faster mirror and a longer timeout are essential. If you're not in China, you can omit the mirror URLs or use another nearby mirror.

2. Downgrade the plugin daemon to version 0.5.3 — if increasing the timeout doesn't help, try changing the image in docker-compose.yaml [1]:

plugin_daemon:
  image: langgenius/dify-plugin-daemon:0.5.3-local

3. Retry the installation — sometimes the first failed attempt populates the uv cache, and a subsequent attempt succeeds because packages are already cached [1].

After making changes, fully recreate the containers:

docker compose down && docker compose up -d

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jiangpeng663]

failed to launch plugin: failed to install dependencies: failed to install dependencies: signal: killed, output: DEBUG uv 0.9.26 DEBUG Acquired shared lock for /root/.cache/uv DEBUG Found project root: /app/storage/cwd/langgenius/agent-0.0.34@4b41a374567eb7cb226ee2f851513794566956008f1166c63205efc921be72d8 DEBUG No workspace root found, using project root DEBUG Acquired exclusive lock for /app/storage/cwd/langgenius/agent-0.0.34@4b41a374567eb7cb226ee2f851513794566956008f1166c63205efc921be72d8 DEBUG No...nd fresh response for: https://files.pythonhosted.org/packages/c2/b0/956902e5e1302f8c5d124e219c6bf214e2649f92ad5fce85b05c039a04c9/zope_event-6.1-py3-none-any.whl DEBUG Sending fresh GET request for: https://files.pythonhosted.org/packages/c2/b0/956902e5e1302f8c5d124e219c6bf214e2649f92ad5fce85b05c039a04c9/zope_event-6.1-py3-none-any.whl Downloading gevent (2.0MiB) Downloading pydantic-core (2.0MiB) Downloading tiktoken (1.1MiB) init process exited due to no activity for 320 seconds failed to init environment However, when I run curl -I https://pypi.org/simple/ and curl -I https://files.pythonhosted.org/ inside the plugin container, both are reachable.
@dosu.

[dosubot[bot]]

Since you've already increased the timeout to 320 seconds and confirmed the network is reachable, the signal: killed strongly suggests the process is being OOM-killed (out of memory) rather than timing out on network. The "no activity for 320 seconds" message appears because the process was killed before it could produce further output.

Here are a few things to try:

1. Check if it's an OOM kill — run this after the next failure to confirm:

docker inspect $(docker ps -q --filter name=plugin_daemon) --format='{{.State.OOMKilled}}'

Or check dmesg | grep -i oom on the host.

2. Ensure the plugin daemon has enough memory — the container has no memory limit by default, but if your host is constrained, you can explicitly allocate more [1]:

plugin_daemon:
  mem_limit: 2g

3. Configure uv-specific PyPI mirror — even though curl works, uv may stall on large parallel downloads. Note that uv does not use PIP_MIRROR_URL; it needs its own variables [2]:

plugin_daemon:
  environment:
    UV_INDEX_URL: https://pypi.tuna.tsinghua.edu.cn/simple
    UV_DEFAULT_INDEX: https://pypi.tuna.tsinghua.edu.cn/simple
    UV_HTTP_TIMEOUT: 120

4. Downgrade the plugin daemon to 0.5.3 — this version has been the most stable for dependency installation [2]:

plugin_daemon:
  image: langgenius/dify-plugin-daemon:0.5.3-local

5. Retry the installation — the first failed attempt often populates the uv cache, and the second attempt succeeds since packages are already cached [2].

After changes, fully recreate containers with docker compose down && docker compose up -d.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jiangpeng663]

[root@iZ2zegazbd8dtdsyqt8k0mZ docker]# docker inspect $(docker ps -q --filter name=plugin_daemon) --format='{{.State.OOMKilled}}'
false
[root@iZ2zegazbd8dtdsyqt8k0mZ docker]# dmesg | grep -i oom
[root@iZ2zegazbd8dtdsyqt8k0mZ docker]# failed to launch plugin: failed to install dependencies: failed to install dependencies: signal: killed, output: DEBUG uv 0.9.26 DEBUG Acquired shared lock for /root/.cache/uv DEBUG Found project root: /app/storage/cwd/langgenius/agent-0.0.34@4b41a374567eb7cb226ee2f851513794566956008f1166c63205efc921be72d8 DEBUG No workspace root found, using project root DEBUG Acquired exclusive lock for /app/storage/cwd/langgenius/agent-0.0.34@4b41a374567eb7cb226ee2f851513794566956008f1166c63205efc921be72d8 DEBUG No...nd fresh response for: https://files.pythonhosted.org/packages/c2/b0/956902e5e1302f8c5d124e219c6bf214e2649f92ad5fce85b05c039a04c9/zope_event-6.1-py3-none-any.whl DEBUG Sending fresh GET request for: https://files.pythonhosted.org/packages/c2/b0/956902e5e1302f8c5d124e219c6bf214e2649f92ad5fce85b05c039a04c9/zope_event-6.1-py3-none-any.whl Downloading tiktoken (1.1MiB) Downloading gevent (2.0MiB) Downloading pydantic-core (2.0MiB) init process exited due to no activity for 320 seconds failed to init environment I have already set the version to dify-plugin-daemon:0.5.3-local and also configured:

but the error still occurs. The output above is what I got after the failure. I used curl -I https://pypi.org/simple/ and curl -I https://files.pythonhosted.org/ to verify network connectivity. What else should I do?@dosu.

[dosubot[bot]]

Good news — OOM is ruled out. The signal: killed in your case is almost certainly the plugin daemon itself killing the uv process after it detects no "activity" for the timeout period. Even though downloads start (tiktoken, gevent, pydantic-core), the daemon may not consider the download progress as "activity," so it kills the process.

Here are additional things to try since the previous suggestions haven't worked:

1. Add PLUGIN_MAX_EXECUTION_TIMEOUT — this is a separate timeout layer that community members report was key to resolving this issue when PYTHON_ENV_INIT_TIMEOUT alone wasn't enough [1]:

plugin_daemon:
  environment:
    PLUGIN_MAX_EXECUTION_TIMEOUT: 2400

2. Increase PYTHON_ENV_INIT_TIMEOUT much higher — 320 seconds may still be insufficient for your network speed. Try 1200 or even 2400 [2]:

    PYTHON_ENV_INIT_TIMEOUT: 1200

3. Configure a PyPI mirror via UV-specific variables (if you haven't already — PIP_MIRROR_URL does NOT work with uv) [3]:

    UV_INDEX_URL: https://pypi.tuna.tsinghua.edu.cn/simple
    UV_DEFAULT_INDEX: https://pypi.tuna.tsinghua.edu.cn/simple
    UV_HTTP_TIMEOUT: 120

4. Try upgrading to dify-plugin-daemon:0.5.4-local instead of 0.5.3 — a newer version is available that may have improvements [4].

5. Retry the installation — the first failed attempt populates the uv cache. A second attempt often succeeds because packages are already downloaded [3].

Full recommended config:

plugin_daemon:
  image: langgenius/dify-plugin-daemon:0.5.4-local
  environment:
    PYTHON_ENV_INIT_TIMEOUT: 1200
    PLUGIN_MAX_EXECUTION_TIMEOUT: 2400
    UV_HTTP_TIMEOUT: 120
    UV_INDEX_URL: https://pypi.tuna.tsinghua.edu.cn/simple
    UV_DEFAULT_INDEX: https://pypi.tuna.tsinghua.edu.cn/simple

Then docker compose down && docker compose up -d and retry.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[jiangpeng663]

When I use this component in a Dify workflow iteration, it runs normally if I choose sequential execution. But when I choose parallel execution, it reports Failed to invoke tool pboc ai test html(new): error: timeout error: signal: killed. Why does this happen?@dosu.

[dosubot[bot]]

This happens because parallel execution sends multiple simultaneous plugin invocation requests to the plugin daemon, which can exhaust resources (memory, workers, timeouts) that are sufficient for sequential execution but not for concurrent load. The signal: killed indicates the plugin process is being terminated — likely due to timeout or resource exhaustion under the parallel workload.

Here's what you can tune to fix this:

1. Increase plugin execution timeouts in your docker-compose.yaml under the plugin_daemon service [1]:

plugin_daemon:
  environment:
    PLUGIN_MAX_EXECUTION_TIMEOUT: 1200
    PYTHON_ENV_INIT_TIMEOUT: 320

2. Increase sandbox worker capacity — the default max_workers: 4 and worker_timeout: 5s in volumes/sandbox/conf/config.yaml are too conservative for parallel workloads. Try increasing them [2]:

max_workers: 8
worker_timeout: 15

3. Add memory limits to the plugin daemon to prevent uncontrolled memory growth that leads to kills [2]:

plugin_daemon:
  mem_limit: 2g

4. Increase the Dify-to-daemon HTTP timeout [3]:

PLUGIN_DAEMON_TIMEOUT: 1200

After changes, restart with docker compose down && docker compose up -d.

If the issue persists, you could also try reducing parallelism in your iteration node (if configurable) or splitting the workload across smaller batches, since the plugin daemon may have internal concurrency limits that can't handle your full parallel load.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[itxashancode]

he previous answer by dosubot: increase timeout and configure a PyPI mirror. Provide environment variables. Actually Dify uses plugin daemon with uv; there is a setting: PLUGIN_INSTALL_TIMEOUT?
In dify, plugin daemon uses a timeout of 120 seconds for no activity. There's an env var PLUGIN_DAEMON_INACTIVITY_TIMEOUT?
I think there is a config in docker-compose: PLUGIN_DAEMON_INSTALL_TIMEOUT maybe. Actually I recall reading about setting PLUGIN_DAEMON_TIMEOUT=300 or UV_TIMEOUT.The error says "init process exited due to no activity for 120 seconds". That's likely from the plugin daemon's watchdog that kills if no stdout/stderr for 120s. There is an env var PLUGIN_DAEMON_INACTIVITY_TIMEOUT seconds.

[jiangpeng663]

I followed the suggestion above and have already resolved it. Thanks.

[itxashancode]

A follow would mean a lot, always happy to connect with people building cool things!

[jiangpeng663]

When I use the iteration node in a Dify workflow, it runs normally if I choose serial mode. However, when I use parallel mode, it returns error: timeout error: sohnal: killed, and neither the input nor the output is displayed.@dosu.