Seafile CE 13.0 (seafileltd/seafile-mc:13.0-latest)
Deployment: Docker Compose, all-in-one container
Host OS: Debian 13
**
Bug: WebDAV dead after container restart — stale PID file not cleaned up**
For a while I noticed that WebDAV would periodically become unreachable. Restarting the Docker stack (or just the seafile container) would bring it back for some time, but the problem always returned. There were no obvious errors — the container was up and healthy, the rest of Seafile worked fine, only WebDAV was dead.
Eventually I traced the root cause:
/opt/seafile/pids/seafdav.pid contained a stale PID — in my case PID 162, which belonged to seafevents, not wsgidav. The seafile-monitor.sh monitoring loop checks whether a service is alive using kill -0 <PID> only, without verifying that the PID actually belongs to a wsgidav process. Since PID 162 (seafevents) was alive, the monitor concluded wsgidav was already running and never started it.
The stale PID file survived container restarts because /opt/seafile/pids/ is bind-mounted to host storage via create_data_links.sh. PID files from a previous container lifetime persist on disk. When a new container starts, seafile-monitor.sh reads the leftover PID file, the naive kill -0 check passes, and wsgidav is never launched.
Proposed fix: On startup, seafile-monitor.sh or the container entrypoint should remove or validate all PID files under /opt/seafile/pids/ before the monitoring loop begins. A check like cat /proc/<pid>/cmdline | grep -q wsgidav is sufficient to detect stale entries.
Feature request: configurable wsgidav log level
The log output from wsgidav is extremely verbose by default. seafdav.log and seafdav.access.log fill up rapidly under normal operation. INFO-level logging is useful when debugging, and access logs are useful if you actually need an access trail — but for a standard production deployment neither is appropriate as a default.
There is currently no supported way to reduce verbosity. The debug flag in seafdav.conf only controls tracebacks, not the log level. The only option is the --verbose=<N> CLI flag, which is hardcoded inside seafile-monitor.sh and not user-configurable.
As a workaround, I set up a separate logrotate config with aggressive size-based rotation to keep disk usage under control. That works, but it should not be necessary — this is something that can and should be solved on the server side by exposing a log level setting.
Request: Please expose a LOG_LEVEL or SEAFDAV_VERBOSE setting in seafdav.conf (or as an environment variable) that is passed as --verbose=<N> to the wsgidav.server.server_cli invocation. Levels 1 (ERROR) or 2 (WARNING) would be the appropriate defaults for production.