A thin wrapper around the installer’s own teardown, so there is one implementation rather than two that drift.
sudo ./install/uninstall.sh --dry-run # print the whole teardown, change nothing sudo ./install/uninstall.sh # do it
It prints every file it would remove, every service it would touch, every question it would ask and the exact answer it would take, and changes nothing at all. That is the flag to use to decide whether to trust it.
It finds the prefix from the installed unit rather than assuming the default, so an install elsewhere is uninstalled from there. Before anything under that prefix is touched, the directory has to look like a Loghound install — an absolute path, not a system directory, containing at least one file only this installer puts there. If it does not, the system integration is still unwound and the directory is left strictly alone.
Eleven steps, printed with their numbers so a run watched over SSH always says where it is. The same eleven, under the same names, are the steps of the panel’s Start over job.
- Services and timers stop first, so nothing recreates what is about to go.
- Proving your account owns these indexes, while the credentials that authorise it still exist.
- Deleting the Loghound indexes, only if you agreed (see below).
- Confirming they are gone from your account, by reading the account’s index list again.
- Web server configuration: the vhost is removed only after the web server validates without it. If the test fails, the server is not reloaded and keeps its last good configuration.
- PHP-FPM pool and its socket.
- Command links and scheduler fragments.
- Credentials and local data, overwritten before they are unlinked.
- Install tree, only if you agreed.
- System user: the log-reading group membership is dropped first, so even a failed delete leaves an account that can no longer read your logs.
- What was NOT removed, printed so you never have to guess.
- Overwrite and remove the credentials? Default yes. That is the configuration file (the API key, the account email, the beacon signing secret, the address salt, any Solr password and the panel password hash), any half-written copy of it, a self-signed private key, the setup token and its ledger, the lockout ledger, the state and job databases, the setup working files, and every PHP session file — because a session file is a signed-in panel session.
- Delete the install directory? Default no.
- Delete the two Opensolr indexes? Default no, and this one is not something a blanket yes can answer — it takes the literal word
DELETEtyped at the prompt. - Remove the system user? Default yes.
On a copy-on-write filesystem, an overlay, a snapshotted volume or any SSD with wear levelling, the write lands in new blocks and the originals remain on the media. Backups and virtual machine snapshots are untouched by definition. If this box is being decommissioned, sold or handed on, rotate the Opensolr API key. That is the only reliable remedy.
Deleting an index destroys its data and burns its name: Opensolr index names are unique across the entire platform and are never released, so neither name can ever be created again, by you or by anyone else.
Only the two indexes this installation provisioned are ever offered. The names are derived from the stored installation id by the same function that created them, checked against the expected shape, required to match what is in the configuration, and then cross-checked against your account’s own index list. No name is read from the command line, no prefix is swept, and nothing else in your account is touched.
If any part of that cannot be checked — the platform is unreachable, the credentials are gone, the configuration is unreadable, the listing comes back empty — nothing is deleted. A check that could not be performed is a failed check. The two names are printed instead, so you can remove them in your control panel if you want to.
Printed at the end of every run, so you never have to guess:
- The beacon script tag on your site. Only you can take that out of your templates.
- A certificate for the panel hostname. Never deleted silently: other vhosts may be using it, and re-issuing after a mistake runs into rate limits. You get the command and the decision.
- The panel’s own access and error logs in your web server’s log directory. Your logrotate owns those.
- Anything you added by hand — a supervisor unit, a firewall rule, a reverse proxy entry, a monitoring check, a backup job. It removes what the installer created and refuses to guess at the rest.
- Your source log files, which were never written to in the first place.
A half-finished install — no configuration, no user, units copied in but never enabled — uninstalls cleanly rather than aborting on the first missing thing.
sudo LOGHOUND_UNINSTALL_DELETE_TREE=yes \
LOGHOUND_UNINSTALL_REMOVE_USER=yes \
./install/uninstall.sh --non-interactive| Variable | Default | Effect |
|---|---|---|
LOGHOUND_UNINSTALL_SHRED_SECRETS | yes | set to no to leave the credentials on disk |
LOGHOUND_UNINSTALL_DELETE_TREE | no | set to yes to remove the install directory |
LOGHOUND_UNINSTALL_REMOVE_USER | yes | set to no to keep the service user |
LOGHOUND_UNINSTALL_REMOVE_LOG | no | set to yes to remove the install log |
LOGHOUND_UNINSTALL_DELETE_INDEXES | no | set to yes to permanently delete the two indexes |
To set Loghound up again instead of removing it: loghound-setup --reset keeps every index and document (Command reference), while Settings › Start over in the panel deletes both indexes and every document in them (Start over).
Operations
- Running it
- Troubleshooting
- Command reference
- Uninstalling