The Oracle keep alive script installs itself from main with no checksum

The installer pulls from a moving branch and verifies nothing

The install is three lines, given twice, once for sh and once for bash:

curl -fsSL https://raw.githubusercontent.com/spiritLHLS/Oracle-server-keep-alive-script/main/oalive.sh -o oalive.sh
chmod +x oalive.sh
sh oalive.sh

The fetch targets the `main` branch by name rather than a tag, and there are no GitHub releases for this repository, so there is no version to point at. Nothing is hashed or signed after the download, and the script is then run. Since it needs root in order to install services, cron entries, configuration and log directories, the fetched file is executed with the highest privilege on the machine at the moment you run it.

That is a normal pattern for a single-file installer, and the flags are chosen to fail quietly rather than leave a partial file. It is worth knowing that the artifact is whatever main happens to hold at fetch time, so a machine that installs twice can end up with two different scripts.

The two variants differ only in the interpreter line, since the runtime was unified to POSIX sh compatibility and can also be launched under bash.

The CPU default changes formula above four cores

CPU occupancy is expressed as a percentage of a single-core quota rather than of total capacity, and the default depends on how many cores the machine has:

On a machine with two to four cores, the default is the core count multiplied by 20 percent. On any other machine, the default is a flat 25 percent.

Those two rules do not join smoothly. A two-core machine gets 40 percent and a four-core machine gets 80 percent, so the band where occupancy scales with cores is exactly the band where a four-core host is loaded harder than a sixteen-core one. A host with five or more cores gets less load than a four-core host by a wide margin.

On systemd the script does not stop at that. It writes a `CPUQuota` value into the unit as well, so the limit is enforced twice, once by the occupancy loop and once by the scheduler.

Memory works on a duty cycle rather than a formula: a default target of 25 percent of total memory, occupying for 300 seconds and resting for 300 seconds. It reads Linux `/proc/meminfo` or BSD `sysctl` metrics, and clamps the allocation by the space available in the temporary directory.

Bandwidth mode estimates a rate when speedtest is missing

The bandwidth occupier runs on a schedule rather than continuously. By default it fires every 45 minutes, downloads for at most 6 minutes, and targets a rate set to 30 percent of whatever the speed test measured.

That measurement is the soft point, and the script is explicit about it. Where no speed test tool exists, bandwidth mode falls back to a default rate estimate instead of raising an error and exiting. So on a host without the tool the ceiling is a guess, and the 30 percent multiplier is applied to a number that came from nowhere.

Source selection is more careful than the rate. Candidates are probed one at a time with short `GET` requests, so a source that only supports `GET` is not wrongly excluded. If every source fails, the round is logged and skipped and the scheduler waits for the next window, and the script does not repeatedly re-request an address that has already proven dead.

Override it from `/etc/oalive/oalive.conf` with a single URL, a comma or space separated list, or a file holding one URL per line. The exposed knobs are `BANDWIDTH_URL`, `BANDWIDTH_URLS`, `BANDWIDTH_URL_FILE`, `BANDWIDTH_URL_CHECKS`, `BANDWIDTH_PROBE_TIMEOUT`, and `BANDWIDTH_PROBE_RATE`. Note that `BANDWIDTH_URL_CHECKS=0` means check every candidate, so a zero in a count variable means unlimited rather than none.

The run locks sit in /tmp, which every local user can write to

Concurrency control is described as atomic directory locks, one per task, and the running lock files are named `/tmp/oalive-*.lock`. Uninstall relies on those locks plus the exact script paths to decide what to stop, explicitly replacing fuzzy process-name matching.

That is a better design than matching on process names, and it is the right call for the stop path. The lock location is the weaker half. `/tmp` is world-writable on every platform this script claims to support, so any local account can create a directory matching the lock pattern ahead of the real task. A pre-existing lock reads as a task already running, which is a way to suppress occupancy without touching any configuration file, and nothing in the documented paths suggests the script distinguishes an owner it created from one it inherited.

Reboot clears the same location, so locks do not survive a restart. That is convenient in the normal case and is the same property that makes the world-writable path worth avoiding on a shared host.

State that does need to persist lives elsewhere: configuration in `/etc/oalive/`, the enabled flag in `/etc/oalive/enabled.conf`, logs under `/var/log/oalive/` with 128 KiB rotation to a single `.1` file, and status data in `/var/lib/oalive/`.

Twelve package managers are detected and nothing says what is installed

The supported platform list is long and specific. Linux covers Debian, Ubuntu, RHEL and CentOS and Oracle Linux and AlmaLinux and Rocky, Fedora, Amazon Linux, Arch, Alpine, openSUSE and SLES, Void, and Gentoo. BSD covers FreeBSD, OpenBSD, NetBSD, and DragonFly BSD, on the condition that they carry cron and the standard POSIX tools.

Scheduling follows from that. Linux with systemd gets systemd; other Linux systems and all BSD go through a cron supervisor, installed as `oalive-cron-runner.sh`.

Then there is the package manager list: `apt-get`, `dnf`, `yum`, `microdnf`, `zypper`, `apk`, `pacman`, `pkg`, `pkg_add`, `pkgin`, `xbps-install`, and `emerge`. Twelve of them, spanning every major Linux family and three BSD variants.

What the page never says is what any of them is used to install. The distribution list and the package manager list read as host detection and dependency resolution, but no dependency is named anywhere, and the installation instructions are only the three curl lines. Since the script requires root, it has the ability to install packages, and the size of the supported matrix suggests it does something with them. If you want to know what lands on the machine before running it, that is the question to put to the code rather than to the documentation.

Four menu entries against five command line verbs

Run with no arguments and the script presents a menu of four choices: install or reinstall the keep alive service, uninstall it, update the installation bootstrap script, and exit.

The command line exposes five verbs instead:

sh oalive.sh --install
sh oalive.sh --uninstall
sh oalive.sh --status
sh oalive.sh --update

`--status` is the extra one. There is no menu entry that reports current state, so inspecting what is installed and scheduled means passing the flag rather than choosing from the list. That is the sensible choice for automation, but it splits the interface in a way the menu does not hint at.

Menu item three is worth noting on its own, because updating the bootstrap is distinct from updating the installed service. The script that installs things and the cron runner it installs are separate files under `/usr/local/bin/`, alongside `cpu-limit.sh`, `memory-limit.sh`, and `bandwidth_occupier.sh`.

After editing `/etc/oalive/oalive.conf` the scheduler has to be told, either with `systemctl daemon-reload` followed by restarts of `cpu-limit.service`, `memory-limit.service`, and `bandwidth_occupier.timer`, or on cron systems with `sh /usr/local/bin/oalive-cron-runner.sh --check`.

Four README files, a tip jar as the homepage, and an explicit no-guarantee note

Documentation is split across four files at the root. The default `README.md` is in Chinese, `README_EN.md` is the English version, and the manual scheduling examples live in `README_CRON.md` with `README_CRON_EN.md` beside them.

The repository metadata points its homepage at a Ko-fi page, which is a donation link rather than a project site, and the only badge on the page is a self-hosted hit counter. There is no documentation site and no release page.

The install path is also unversioned in a second way. The systemd unit files, `cpu-limit.service`, `memory-limit.service`, `bandwidth_occupier.service`, and `bandwidth_occupier.timer`, sit at the repository root next to `oalive.sh` and the `scripts/` directory rather than in a packaging folder. There is no package for any of the twelve package managers it detects; installation is the script copying files into `/usr/local/bin` itself.

The most important text on the page is the note under its own heading. It says there is no guarantee that resource occupancy affects a cloud provider's reclamation policy, and that the project only offers controllable, uninstallable, low-risk occupancy tasks, leaving you to judge by the service provider's terms and your own actual use. That sentence is the honest summary of what this tool is, and it is worth reading before the configuration examples.

Editorial conclusion

Check your cloud provider's terms before you run this, because that is the question the project itself declines to answer: its documentation states there is no guarantee that resource occupancy affects a provider's reclamation policy, and asks you to judge by the service terms and your own actual use. If your provider permits it and your instance is genuinely low-load, the script is competently built for the job. It runs under POSIX sh, degrades instead of failing across twelve package managers and both BSD and Linux scheduling paths, uses atomic directory locks rather than process-name matching, and uninstalls cleanly and repeatably. Two operational cautions. The install fetches whatever is currently on the main branch and verifies no checksum, so pin a commit if you care about reproducibility. And the run locks live in /tmp, which any local user can write to and which clears on reboot, so treat a shared host as outside what this design protects.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. spiritLHLS/Oracle-server-keep-alive-script on GitHub