Dear Maintainer,

The start() function in /etc/init.d/spice-vdagent unconditionally
removes /var/run/spice-vdagentd/spice-vdagent-sock before invoking
start-stop-daemon.

If spice-vdagentd is already running, start-stop-daemon --start
--oknodo leaves the existing daemon running and returns success.
However, its listening socket pathname has already been removed,
preventing graphical session agents from connecting.

Environment:
- Devuan Excalibur
- runit as PID 1
- Xfce/X11
- QEMU/KVM with SPICE and the com.redhat.spice.0 virtio channel

Observed behavior:
Clipboard sharing stopped working although service status reported
spice-vdagentd running. The graphical session agent subsequently
exited. Starting it in the foreground produced:

  Failed to connect with spice-vdagentd due 'Could not connect:
  No such file or directory'. Trying again in 1s

After terminating and restarting spice-vdagentd, the agent connected:

  connected to /run/spice-vdagentd/spice-vdagent-sock

Expected behavior:
Calling start on an already-running service should leave its
communication socket intact.

Reproduction procedure for the unmodified init script:
1. Start the daemon and confirm its socket exists.
2. Invoke /etc/init.d/spice-vdagent start again.
3. Observe that the daemon remains running, but the socket pathname
   has disappeared.
4. A newly launched spice-vdagent cannot connect.

The original trigger for the socket disappearance was not traced,
but inspection identified the non-idempotent start operation above.
Adding the following guard fixed the problem on my system:
--- a/etc/init.d/spice-vdagent
+++ b/etc/init.d/spice-vdagent
@@ -36,6 +36,10 @@
 lockfile=/var/lock/$prog

 start() {
+    # An already-running daemon must retain its communication socket.
+    if status_of_proc -p "$pidfile" "$exec" "$prog" >/dev/null 2>&1; then
+        return 0
+    fi
     [ -x $exec ] || exit 5
     [ -c $port ] || exit 0
     modprobe uinput > /dev/null 2>&1

This uses the same process-status helper and PID file already used
by the script's status() function.

The bug was discovered and the report was written with the help of
OpenAI's codex.