Oracle-server-keep-alive-script: generating CPU, memory and bandwidth load on Oracle Cloud free instances

What this solves, and for whom

The project targets low-load machines, and its own description names Oracle Cloud as the main case. The premise is that a server sitting idle at near-zero CPU, memory and network activity may be treated differently by a provider's reclamation policy than one showing steady use. The script does not change the instance, the billing plan or the provider's rules. It generates occupation on three axes the README lists as selectable: CPU, memory and bandwidth.

Who is it for? People running small Oracle Cloud instances, particularly ARM shapes, who want a scheduled load rather than a hand-written loop in a tmux session. The repository is written in Shell, licensed MIT, and its last push was on 2026-09-26. The README is explicit that whether resource occupation affects a cloud provider's reclamation policy is not guaranteed, and asks users to judge for themselves against the provider's terms and their own purpose. That sentence is the honest boundary of the project, and it should be the boundary of your expectations too.

It is not a monitoring agent, not a cost tool and not a reclamation predictor. It is a scheduler plus three small occupation scripts.

How the occupation tasks are actually scheduled

The installer picks a scheduler based on what the machine has. On Linux with systemd it installs cpu-limit.service, memory-limit.service and bandwidth_occupier.timer. On Linux without systemd, and on BSD, it installs a cron supervisor named oalive-cron-runner.sh instead. The README describes this as automatic degradation, and the same idea applies to package managers: apt-get, dnf, yum, microdnf, zypper, apk, pacman, pkg, pkg_add, pkgin, xbps-install and emerge are all listed as handled.

The CPU logic works as a percentage of a single-core quota. Machines with 2 to 4 cores default to core count times 20 percent, other machines default to 25 percent, and in systemd environments the installer also writes CPUQuota so the limit is enforced twice. Memory defaults to 25 percent of total memory, occupied for 300 seconds then rested for 300 seconds; the script reads /proc/meminfo on Linux or sysctl metrics on BSD and clamps the amount by the free space in the temporary directory. Bandwidth fires every 45 minutes by default, downloads for at most 6 minutes, and uses 30 percent of the measured speed. Download sources are ordinary static test files probed one by one; if every source fails, the round is skipped and the next scheduled run is awaited rather than retrying dead special-purpose URLs.

Concurrency is handled with atomic directory locks, and uninstall stops tasks by lock and exact script path rather than by fuzzy process-name matching. Logs go to /var/log/oalive and rotate to a .1 file at 128 KiB by default.

Installing it and running a first occupation round

The README gives a curl download followed by chmod and execution. The script needs root, because it installs services, cron entries, configuration and log directories. Run the following and you should land in an interactive menu with four entries: install or reinstall, uninstall, update the bootstrap script, and exit.

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

If you prefer bash, the README shows the same download with bash oalive.sh at the end. The menu is not the only entry point; command-line arguments exist for scripted use.

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

After an install, configuration lives at /etc/oalive/oalive.conf and enablement state at /etc/oalive/enabled.conf. The bandwidth source list can be overridden with a single URL, a comma or space separated list, or a file with one URL per line. Probing uses short GET requests so that GET-only sources are not wrongly excluded, and BANDWIDTH_URL_CHECKS=0 means every candidate is checked.

BANDWIDTH_URL=""
BANDWIDTH_URLS="https://example.com/large-file.bin,https://mirror.example.com/large-file.bin"
BANDWIDTH_URL_FILE=""
BANDWIDTH_URL_CHECKS=0
BANDWIDTH_PROBE_TIMEOUT=5
BANDWIDTH_PROBE_RATE=16384

After editing the file, restart the relevant scheduler. The README gives the systemd path and the cron path separately.

systemctl daemon-reload
systemctl restart cpu-limit.service memory-limit.service
systemctl restart bandwidth_occupier.timer

On a cron-based machine the equivalent check is sh /usr/local/bin/oalive-cron-runner.sh --check. The README points to README_CRON.md for more manual scheduling examples.

Where the design gets thin

The most important limitation is stated by the project itself: resource occupation may or may not influence a provider's reclamation policy, and no guarantee is offered. Anyone installing this to protect an instance should read that line twice. The script is a load generator with a scheduler, nothing more.

The defaults also deserve scrutiny. Memory occupation is a flat 25 percent of total memory with a 300-second on, 300-second off cycle. On a small instance that is a modest, intermittent footprint; on a large one it is a fixed fraction that does not adapt to what the machine is actually doing. The bandwidth mode depends on external static files, and the README acknowledges that when all sources are unreachable the round is skipped. A skipped round is the correct behaviour, but it also means the bandwidth axis can silently contribute nothing for a stretch of time, and the log is where you would notice. The CPU percentage is expressed against a single-core quota and doubled up with CPUQuota under systemd, which is a sensible belt-and-braces choice, yet it also means the effective ceiling depends on which scheduler path your machine took.

None of this is a defect in the sense of a bug. It is the shape of a tool that must work across Debian, Alpine, FreeBSD and openSUSE with the same script. The cost of that portability is that the defaults are conservative and coarse.

Alternatives and how they differ

The most direct alternative is writing your own cron entries around stress-ng or a dd loop. That gives you exact control over load shape and timing, and no installer to trust. What you give up is the packaging this project provides: atomic directory locks against concurrent re-entry, an uninstall that stops tasks by exact script path instead of matching process names, log rotation at 128 KiB under /var/log/oalive, and a single configuration file at /etc/oalive/oalive.conf. If you already run configuration management, a hand-written unit file may fit your setup better; if you are SSHing into one free instance, the installer is less work.

A second alternative is to give the instance real work instead of synthetic load. Running a small service, a build runner or a monitoring probe produces CPU, memory and network activity as a side effect, and the activity is useful rather than wasted. That approach is strictly better on the merits, and it is the right answer whenever you can find a workload you actually want. The keep-alive script exists for the case where you cannot, and it is honest about being a fallback.

Maintenance, upgrade cost and licence

The repository is not archived, and the last push was on 2026-09-26. Upgrades go through the same entry script: the menu offers an option to update the bootstrap script, and the README also documents sh oalive.sh --update. That is the whole upgrade story. There are no retrieved releases, so there is no versioned changelog to read before an update; you are pulling the current main branch script.

Because the project is a shell script that installs files under /etc, /var/log, /var/lib and /usr/local/bin, the practical maintenance cost is the surface it touches. Uninstall is documented as safe to repeat and cleans running scripts, configuration, state files and locks, which lowers the cost of trying it and backing out. The licence is MIT. That permits commercial and private use and modification, and it comes with no warranty, which matches the README's own statement that no guarantee is offered about provider behaviour. Nothing here is legal advice; check the licence file and your provider's terms yourself.

The repository also ships README_CRON.md and README_CRON_EN.md alongside the main README, so cron users have a separate document to consult when the automatic path does not match their machine.

Editorial conclusion

Adopt it if you run an idle Oracle Cloud ARM instance and want a removable, inspectable load generator with systemd or cron scheduling and logs under /var/log/oalive. Do not adopt it if you expect a guarantee against instance reclamation: the README states there is no such guarantee, and the script only provides controllable occupation tasks. Before installing, check that you have root, that the target filesystem has space for the logs and state directories, and that /etc/oalive/oalive.conf matches your machine's core count, because the CPU defaults scale with core count and the memory target is a fixed 25 percent of total memory.

Frequently asked questions

Official sources

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