How to start/stop/enable/disable manually OpenClaw, Hermes, Signal?

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:

Bash

# 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:

Bash

# 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:

Bash

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.service

• To 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:

Bash

systemctl --user list-unit-files | grep -i openclaw

If it appears there, run:

Bash

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:

Bash

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:

Bash

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 bash or python, 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:

Bash

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:

Bash

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):

  Bash

  systemctl --user start hermes-gateway.service
  

• To start Signal (System level):

  Bash

  sudo systemctl start signal-daemon.service
  

  (Note: I removed --user here. If you specifically installed Signal as a user service, just run systemctl --user start signal-daemon.service without 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:

Bash

ps -up 4757

Why this helps:

• It will show the Command line used to start it.

• If it says something like python3 openclaw.py or ./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?

 

 

How can I prevent the NetworkManager-wait-online.service from starting at boot on Ubuntu 24.04?

You can prevent the NetworkManager-wait-online.service from starting at boot on Ubuntu 24.04 using the systemctl command to either disable or mask the service.

This service's purpose is to delay the boot process until the network connection is fully established, which can cause significant delays if the network is slow or unavailable. Disabling it is generally safe for desktop users who don't rely on network resources (like remote mounts or network-dependent services) immediately after startup.

---

🛑 How to Disable the Service

The recommended and most common approach is to use the disable command. This removes the symlink that causes the service to start automatically.

1. Run the disable command:

   Bash

   sudo systemctl disable NetworkManager-wait-online.service
   

2. Reboot your system to confirm the change.

🎭 If Disabling Doesn't Work: Masking (The Stronger Approach)

In some cases, another service might still have a dependency that causes the NetworkManager-wait-online.service to be started anyway. If the disable command doesn't work, you can mask the service. Masking creates a symlink to /dev/null, preventing any service from starting it, even manually or as a dependency.

1. Run the mask command:

   Bash

   sudo systemctl mask NetworkManager-wait-online.service
   

2. Reboot your system.

---

↩️ How to Revert the Change

If you later find that you need the service to wait for the network (for example, if a service or application that relies on an immediate network connection fails to start), you can easily revert the changes.

• For a Disabled Service:

  Bash

  sudo systemctl enable NetworkManager-wait-online.service
  

• For a Masked Service:

  You must first unmask it, and then enable it:

  Bash

  sudo systemctl unmask NetworkManager-wait-online.service
  sudo systemctl enable NetworkManager-wait-online.service
  

Would you like to check which other services are delaying your boot time using systemd-analyze blame?

Can I prevent the service from starting at boot by editing any text file?

Yes, you can prevent the NetworkManager-wait-online.service from starting at boot by editing a text file—specifically, by manually removing the symbolic link that is created when the service is "enabled."

The systemctl disable command is just an automated way of doing this file manipulation.

---

1. Deleting the Systemd Symlink

When a systemd service is "enabled," a symbolic link is created in a "wants" directory that points to the main unit file. Removing this link is equivalent to running systemctl disable.

For NetworkManager-wait-online.service, the symlink is usually found in the multi-user.target.wants directory, which controls services that start up for a multi-user environment.

1. Navigate to the multi-user.target.wants directory:

   Bash

   cd /etc/systemd/system/multi-user.target.wants/
   

2. Delete the symbolic link:

   Bash

   sudo rm NetworkManager-wait-online.service
   

3. Reload the systemd manager configuration (Required):

   After making a manual change to a unit file or its symlinks, you must tell systemd to re-read its configuration:

   Bash

   sudo systemctl daemon-reload
   

4. Verify the service is now disabled:

   Bash

   systemctl is-enabled NetworkManager-wait-online.service
   

   This should now output disabled.

---

2. The Stronger File-Based Method: Masking

If simply disabling the service doesn't work (because another service has a dependency that still triggers it), you need to "mask" the service. Masking is the strongest way to prevent a systemd unit from starting, and it is also done by manipulating a file.

Masking is achieved by creating a symbolic link in /etc/systemd/system that points to /dev/null. This tells systemd to effectively ignore the service.

1. Create the symbolic link to /dev/null:

   Bash

   sudo ln -s /dev/null /etc/systemd/system/NetworkManager-wait-online.service
   

2. Reload the systemd manager configuration (Required):

   Bash

   sudo systemctl daemon-reload
   

3. Verify the service is now masked:

   Bash

   systemctl status NetworkManager-wait-online.service
   

   The output will show the service as "masked".

Note: The systemctl disable and systemctl mask commands are the recommended way to do this, as they handle the file system pathing and the necessary daemon-reload for you, reducing the chance of error.

As you suggested earlier, could you let me know how to check which other services are delaying my boot time using systemd-analyze blame, please? Thank you!

Yes! The tool is called systemd-analyze, and the subcommand you want is blame. ¹It generates a list of all startup services, sorted by the time they took to initialize, with the longest delays at the top.²

Here is a step-by-step guide on how to use it.

---

💻 Step 1: Run the systemd-analyze blame Command

Open your terminal and run the following command. You do not need sudo for this command.

Bash

systemd-analyze blame

Example Output

The output will look similar to this, with the slowest services listed first:

Time	Service
5.417s	NetworkManager-wait-online.service
1.275s	udisks2.service
1.054s	snapd.service
789ms	dev-sda5.device
452ms	apache2.service
230ms	systemd-udev-settle.service

---

🔍 Step 2: Analyze the Output

The list shows the services, or units, in descending order of how long they spent in the "activating" state during the last boot.³

• The first column shows the time taken (e.g., 5.417s for 5.417 seconds).⁴

• The second column is the name of the unit (e.g., NetworkManager-wait-online.service).

Key Takeaways:

1. Identify Offenders: Focus on the services at the very top of the list (like NetworkManager-wait-online.service in the example above).⁵ These are the main "culprits" that added the most time to your overall boot.

2. Units Run in Parallel: Keep in mind that many services run at the same time.⁶ You cannot simply add all the times together to get your total boot time. The list helps you spot single services that spend a lot of time by themselves.

---

🌲 Step 3: Check the Critical Chain (Optional but Recommended)

While blame shows you which services took the longest, the critical-chain subcommand is better for identifying bottlenecks—services that block the boot process until they complete.⁷

Bash

systemd-analyze critical-chain

Example Output

graphical.target @20.123s
└─multi-user.target @20.123s
  └─ NetworkManager-wait-online.service @14.706s +5.417s
    └─ NetworkManager.service @13.900s +780ms
      └─ dbus.service @13.890s

• @ (At): The time when the unit became active or started.

• + (Plus): The time the unit took to start (the delay).⁸

In this example, the chain shows that NetworkManager-wait-online.service (which took +5.417s) was a dependency for the main target to be reached. This confirms it was a blocker, just as you suspected!

You can also generate a visual SVG graph of the boot process for a more intuitive view of dependencies and parallel startup, by using the following command:

Bash

systemd-analyze plot > boot.svg

You can then open the boot.svg file in a web browser to see a detailed, color-coded timeline.

---

Once you've identified the high-time services, you can then use systemctl disable or systemctl mask (as discussed in our previous exchange) on non-essential ones to speed up your boot.