Sherman:
Gemini, both my OpenClaw agent and Hermes agent start automatically when my laptop is turned on. Even when I kill both the processes, both start again in a few seconds.
Could you instruct me to change it, so both do not start automatically, please? I prefer that I start either of the both manually.
Gemini:
It sounds like you're playing a game of "whack-a-mole" with your processes! The reason they keep coming back is that they are managed by systemd. When you kill a process managed this way, systemd sees the "failure" and immediately restarts it to ensure the service stays active.
Based on your setup, here is how to stop them from starting automatically and switch to manual control.
1. Disable the Hermes Gateway (User Service)
Your Hermes agent is running as a user-level service. You’ll need to stop the current instance and then "disable" it so it doesn't launch at boot.
Run these commands in your terminal:
# Stop the running service
systemctl --user stop hermes-gateway.service
# Prevent it from starting at boot
systemctl --user disable hermes-gateway.service
2. Disable the Signal Daemon (System Service)
Since the Signal daemon (which supports Hermes) runs as a system-wide service, you'll need to use sudo for these:
# Stop the daemon
sudo systemctl stop signal-daemon.service
# Disable it from starting at boot
sudo systemctl disable signal-daemon.service
3. Regarding OpenClaw
If you are seeing an OpenClaw-related process despite having uninstalled it previously, it might be a leftover service unit or a different script triggering it. You can check if a service still exists for it by running:
systemctl list-unit-files | grep -i openclaw
If it shows up, run:
sudo systemctl stop openclaw.service
sudo systemctl disable openclaw.service
How to start them manually from now on
Whenever you actually want to use them, you don't need to change your configuration back. Just "start" them for that session only:
To start Hermes:
systemctl --user start hermes-gateway.serviceTo start Signal:
sudo systemctl start signal-daemon.service
Note: Since you have "lingering" enabled for your user account, these services would normally stay running even if you logged out. Disabling them as shown above is the correct way to ensure they only run when you explicitly ask them to.
Does that clear up the "auto-restart" headache for you?
Sherman:
shermanchen@serverlenovo:~$ systemctl list-unit-files | grep -i openclaw
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$ lsof -i :18789
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openclaw- 4757 shermanchen 22u IPv4 34619 0t0 TCP localhost:18789 (LISTEN)
openclaw- 4757 shermanchen 23u IPv6 34620 0t0 TCP ip6-localhost:18789 (LISTEN)
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$
shermanchen@serverlenovo:~$ sudo systemctl stop openclaw.service
Failed to stop openclaw.service: Unit openclaw.service not loaded.
shermanchen@serverlenovo:~$
Gemini:
That is definitely a bit of a "ghost in the machine" situation! Since systemctl doesn't see a service file, but the process is clearly running and listening on port 18789, it isn't being managed by a standard system-wide service.
The fact that it restarts after being killed suggests something else is acting as a "watchdog." Here is how to track down what is actually triggering it:
1. Check User-Level Systemd Services
Since you are logged in as shermanchen and the process is owned by you, it might be a user-service rather than a system-service. Your previous command only checked the system level.
Try this:
systemctl --user list-unit-files | grep -i openclaw
If it appears there, run:
systemctl --user stop openclaw.service
systemctl --user disable openclaw.service
2. Check for a Crontab "Keep-Alive"
Sometimes scripts are set to run every minute via Cron to make sure they are alive. Check your user crontab:
crontab -l
Look for any line referencing openclaw or a script that might be starting it.
3. Inspect the Process Parent
To see exactly "who" is responsible for starting that PID 4757, you can look at the process tree. This will tell us if it was started by systemd, screen, tmux, or another script.
Run:
ps -fjp 4757
Look at the PPID (Parent Process ID). * If the PPID is 1, it’s a daemon/systemd.
If the PPID leads to something like
bashorpython, it’s a script loop.
4. Search for the Binary Location
Since you thought you uninstalled it, let's find out exactly where this running version lives:
ls -l /proc/4757/exe
This will show you the absolute path to the file that is currently running.
5. Check "Lingering" and PM2
If you have ever used PM2 (a common process manager for developers), it might be managing it silently. Check with:
pm2 list
What to do next:
If the systemctl --user command from Step 1 doesn't find it, please let me know what the PPID and the path from Steps 3 and 4 are. That will give us the smoking gun!
Sherman:
shermanchen@serverlenovo:~$ systemctl --user start hermes-gateway.service
shermanchen@serverlenovo:~$ sudo systemctl --user start signal-daemon.service
Failed to connect to bus: No medium found
Gemini:
It looks like you ran into a classic systemd permissions mix-up!
The error Failed to connect to bus: No medium found usually happens when you try to run a user command with sudo. Because sudo switches you to the "root" user, it loses track of your specific user's "bus" (the communication channel for your user-level services).
Here is the quick fix for both services:
1. The Correct Commands
For Hermes, you did it perfectly the first time. For the Signal Daemon, it depends on how it was installed. If it's a system-wide service, you don't use the --user flag.
To start Hermes (User level):
Bashsystemctl --user start hermes-gateway.serviceTo start Signal (System level):
Bashsudo systemctl start signal-daemon.service(Note: I removed
--userhere. If you specifically installed Signal as a user service, just runsystemctl --user start signal-daemon.servicewithout sudo.)
2. Back to the "Ghost" OpenClaw
Since you are still seeing OpenClaw running on port 18789, let's try one more targeted command to see exactly what is keeping it alive. Run this:
ps -up 4757
Why this helps:
It will show the Command line used to start it.
If it says something like
python3 openclaw.pyor./openclaw-linux, we’ll know the exact file location.
One other possibility:
Do you use Docker? Sometimes a container is set to restart: always. You can check by running:
docker ps | grep openclaw
If you find the path or the parent process, I can give you the exact command to kill it for good (or at least until you're ready to use it manually). What does that ps -up 4757 output look like?
