Skip to content
GuardiozBeta

Remove Guardioz from a server

These steps remove Guardioz from one server, and then delete that server in Guardioz. There is no uninstall command: each step undoes one change that the installer made. The install manifest on the server records many of those changes, each with the command that reverses it. This page also covers the changes that the manifest does not record. The examples use the port 5432. Replace 5432 with the port of your PostgreSQL instance.

These steps remove:

  • the agent service and the agent files on this server;
  • the monitoring role guardioz_monitor and the pg_hba.conf lines that the installer added for it;
  • the access entries that let the agent reach the data directory;
  • the system account that the agent’s service uses;
  • the server with its snapshots and findings in Guardioz.

They remove only what the installer created. They leave the data, the settings and the other roles of your database, because the installer changed none of them. Anything that was on the server before the installation stays where it is, and the steps say how to recognise that case.

Removing the agent from the server does not delete the server in Guardioz, and deleting the server in Guardioz does not remove anything from the server. Do both, in the order on this page.

Before you start

Section titled “Before you start”

  • Administrator rights on the server that runs PostgreSQL: the root account, or an account that can use sudo.

  • A way to run SQL on that instance as a database superuser.

  • The ports that Guardioz monitors on this server. There is one configuration file and one service for each of them. To list the configuration files, run this on the server:

    Terminal window
    sudo ls /etc/guardioz-agent/

    A file named config-5432.yaml belongs to the instance on port 5432. Repeat the steps for every port you find.

The Linux commands on this page use sudo. As root, leave out sudo. The FreeBSD commands are written for root.

Remove the agent from the server

Section titled “Remove the agent from the server”

  1. Keep a copy of the install manifest. Step 3 deletes the directory that holds it, and the later steps use the lines it contains.

    Terminal window
    sudo cp /etc/guardioz-agent/install-manifest.txt ~/guardioz-install-manifest.txt

    The file lists each change that the installer recorded, as a description line that starts with # and the command that reverses that change. Nothing in it runs on its own. What the file holds per operating system: What the installer changes on your server.

  2. Stop the service of each monitored port and remove it.

    Terminal window
    sudo systemctl disable --now guardioz-agent-5432
    Terminal window
    sudo rm -f /etc/systemd/system/guardioz-agent-5432.service

    After the last port, tell systemd that the unit files are gone:

    Terminal window
    sudo systemctl daemon-reload

  3. Delete the agent files. This removes the agent code and every kept previous version, the configuration files of all ports, the manifest, and the file that records when the daily and the weekly collection last ran.

    Terminal window
    sudo rm -rf /opt/guardioz-agent /etc/guardioz-agent /var/lib/guardioz-agent

    /opt/guardioz-agent also holds the Python libraries that the installer installed for the agent alone, so this removes them too.

  4. Remove the two lines that the installer can add to pg_hba.conf, the file that decides who can connect to PostgreSQL. Repeat this step on each monitored instance: every instance has its own file.

    A wrong edit in that file can stop your applications from connecting. Copy the file before you change it, delete only the two Guardioz lines, and keep the copy until your applications have connected again.

    The installer adds the lines only when the monitoring role cannot log in over the local socket, so a file without these lines is a normal result.

    To find the file, run this in an SQL session as a superuser:

    SHOW hba_file;

    Open that file with administrator rights, and delete both of these lines when they are there:

    # Guardioz monitoring (read-only, local socket only)
    local  all  guardioz_monitor  scram-sha-256

    Your manifest copy can hold an undo line for this change. Do not use it: it removes the second of the two lines and leaves the first one. Delete both lines by hand, and leave that undo line out of step 6.

    Then load the file into the running server, in an SQL session as a superuser:

    SELECT pg_reload_conf();

  5. Remove the monitoring role, in an SQL session on that instance as a superuser. Repeat this step on each monitored instance.

    First find out whether the installer created that role. Look in your manifest copy for a description line that starts with # created monitoring role: one such line names the port on which the installer created the role.

    When the installer created the role, remove it:

    DROP ROLE guardioz_monitor;

    When a role of that name was on the instance before the installation, keep it. Remove only the permission that the installer granted:

    REVOKE pg_monitor FROM guardioz_monitor;

    The installer also gave that role a new password, and these steps cannot bring the old one back. When something on your server signs in with this role, set the password you want yourself, in an SQL session as a superuser:

    ALTER ROLE guardioz_monitor PASSWORD 'the password you choose';

    When you cannot tell which of the two cases you are in, run the REVOKE statement. It leaves the role on the instance and takes back the permission that the installer gave it.

    If PostgreSQL refuses to remove the role because objects depend on it, do not force it. The installer creates no database object, so those objects belong to something else on that instance. Leave the role where it is and run the REVOKE statement instead.

  6. Open your manifest copy and run the undo lines that are left in it. They run in a shell on the server, as root or with sudo.

    Terminal window
    less ~/guardioz-install-manifest.txt

    Two kinds of entry are left, and the order matters: first each line that removes an access entry on a directory, then the line that removes the system account. Each access line names the account, so it works while the account still exists. The other entries describe changes that steps 2 to 5 have already undone, except the entry for the acl package, which step 7 covers.

    The description of an access-entry line starts with # traverse ACL for, and the description of the account line starts with # created the system account. When your copy has no account line, the installer did not record creating an account. Leave the account on the host as it is. An agent update can also create that account without recording it, so write to contact@guardioz.com when you want the account removed as well.

  7. Optional: Remove the software that the installer added for the agent.

    Your manifest copy holds an entry that describes the acl package when this installation added it, and that entry says how to remove the package with your package manager. When you are not sure whether something else on the host uses it, leave it: nothing of Guardioz uses it after this removal.

Check that nothing is left

Section titled “Check that nothing is left”

On the server, look for the agent services and the agent directories:

Terminal window
systemctl list-unit-files 'guardioz-agent-*'
Terminal window
ls -d /opt/guardioz-agent /etc/guardioz-agent /var/lib/guardioz-agent

The first command lists no agent service. The second reports for each of the three paths that it does not exist.

In an SQL session on each monitored instance, this query returns no row when you removed the role:

SELECT rolname FROM pg_roles WHERE rolname = 'guardioz_monitor';

Something that is still there: Update and removal problems.

Delete the server in Guardioz

Section titled “Delete the server in Guardioz”

The server stays in Guardioz with its history until you delete it.

In Guardioz, open Servers, and then click Delete in the row of that server. The browser asks Are you sure you want to delete server NAME?, with the name of that server in place of NAME, and deletes the server when you confirm. What the deletion removes: Manage your servers.

Delete the server after you have removed the agent from the host. An agent that still runs keeps running and writes an authentication error to its log, because its collector key was deleted together with the server. That error appears once per collection, and the installer sets one collection per hour.

If something goes wrong

Section titled “If something goes wrong”

Next steps

Section titled “Next steps”
What the installer changes on your serverThe full list of changes, per operating system, and the record that holds them.
Manage your serversThe Servers list, the server page, and what deleting a server removes.
Install the agentInstall Guardioz on this server again, or on another one.