Try the following first. After that reuse the info in my previous post:
# See current limits
sysctl fs.inotify.max_user_watches fs.inotify.max_user_instances fs.inotify.max_queued_events
# Temporarily raise them (takes effect immediately, lasts until reboot)
sudo sysctl -w fs.inotify.max_user_watches=1048576
sudo sysctl -w fs.inotify.max_user_instances=4096
sudo sysctl -w fs.inotify.max_queued_events=65536
# Try again
sudo systemctl daemon-reload
sudo systemctl restart manager-server
sudo systemctl status manager-server --no-pager
THEN:
sudo tee /etc/sysctl.d/99-inotify.conf >/dev/null <<'EOF'
fs.inotify.max_user_watches=1048576
fs.inotify.max_user_instances=4096
fs.inotify.max_queued_events=65536
EOF
sudo sysctl --system
(Optional) Find whatās hogging watches
GUI file indexers, IDEs, sync tools (e.g., Syncthing/Dropbox), container stacks, or dev servers can leak watches.
# Show processes with inotify fds
sudo lsof -n | grep inotify | awk '{print $1,$2}' | sort | uniq -c | sort -nr | head
# Or per-PID count
for p in /proc/[0-9]*; do c=$(ls -l $p/fd 2>/dev/null | grep -c inotify); [ "$c" -gt 0 ] && printf "%6d %s\n" "$c" "$(ps -p ${p##*/} -o comm=)"; done | sort -nr | head
Why this affects your service
systemd (PID 1) runs as root and uses inotify to monitor cgroup control files. If rootās max_user_watches/max_user_instances are already used up (often by container engines, log shippers, or aggressive file watchers), starting any new service can trigger this error.
After raising limits
If you still see the error:
sudo systemctl stop manager-server
sudo systemctl daemon-reload
sudo systemctl start manager-server
journalctl -u manager-server -n 200 --no-pager
Thatās itāraising the inotify limits and/or stopping the watch-heavy culprit resolves this.
