Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Basic Operations Manual: Service Restart Order, Log Locations, and Common Error Code Reference Table

In partner training, the operations manual is not meant to teach everyone how to modify code. The goal is to ensure everyone knows where to look for problems, how to restart services, and how to categorize exceptions.

While much of this content comes from delivery experience, it is not entirely without public backing. The official Compose and self-hosting documentation already provides service names and basic runtime information. Therefore, “which logs to check and which services to restart” can at least be grounded in the publicly documented service structure. Community articles also supplement this with frontline troubleshooting cases such as Weaviate errors after upgrades, Internal Server Errors, and 500 errors.

1. Operations Anchor Points Confirmed by Public Sources

1. First Identify Service Roles, Then Discuss Restart Order

The official documentation publicly lists services including api, worker, worker_beat, web, plugin_daemon, sandbox, db_postgres, redis, and others. Therefore, basic operations training should first help trainees build a mental model of “which service corresponds to which type of failure symptom.”

2. Log Viewing Paths for Compose and Kubernetes Are Publicly Confirmed

For Compose, use docker compose logs <service> directly. For Kubernetes, use kubectl logs, and troubleshoot at the deployment and pod level. These are the most fundamental and practical actions in training.

3. Public Community Articles Already Cover Some Typical Errors

Examples include Weaviate version incompatibility, Internal Server Errors on Azure VMs, and exceptions caused by knowledge pipelines. These indicate that Dify operations issues are often distributed across dependent components, version upgrades, and file processing pipelines.

If only the frontend is experiencing issues, do not perform a full restart. Follow the principle of minimal impact:

  • Single service restart
  • Dependency service check
  • Full stack restart only as a last resort

3. Log Locations

  • Docker Compose: docker compose logs <service>
  • Kubernetes: kubectl logs deployment/<name> or pod-level logs
  • Focus on api, worker, enterprise, and sandbox

4. Common Error Categories

  • Authentication / permission errors
  • Database connection errors
  • Redis / queue errors
  • Object storage errors
  • Vector database retrieval errors
  • External model provider errors

If your team already has an internal common error code reference table, it is recommended to add it directly to this document. Public sources typically do not cover delivery-site troubleshooting experience this comprehensively.

Public Source References

note.com

  • Complete guide to running Dify and n8n on a single VPS, reducing costs from 10,000 yen to 1,000 yen per month, with SSL support and troubleshooting | https://note.com/ai_restart/n/nd882767068c6

zenn.dev / Official Documentation / Other Public Pages

  • Deploy Dify with Docker Compose (Japanese) | https://docs.dify.ai/ja/self-host/quick-start/docker-compose
  • How to fix “Weaviate 1.19 is not supported” error after Dify update | https://zenn.dev/kotap/articles/ea3b5995b8ba44
  • Causes and solutions for “Internal Server Error” on Dify running on Azure VM | https://zenn.dev/ytksato/articles/6cb73e68a568e6

Confirmed Information from Public Sources

  • Basic operations should first establish the mapping between service roles and failure symptoms
  • Log viewing paths for Compose and Kubernetes are publicly documented
  • The community has already accumulated frontline cases involving upgrade errors, 500 errors, and dependent component anomalies