How to Install and Configure Uptime on Linux

— ny_wk

Installing the up.time agent on Linux means deploying an RPM package, registering a service user, exposing the agent on TCP port 9998 through the xinetd super-daemon, and verifying that the monitoring station can reach it. This guide walks through the full process step by step, corrects the rough spots in older vendor instructions, and explains how to validate the install before you ever add the host to a dashboard.

Important context first: up.time (also written uptime software) was a commercial server-monitoring suite. The vendor was acquired by Idera and the product line was retired, so version 5.x agents are end-of-life. If you are inheriting a legacy environment that still runs it, this guide remains accurate for keeping those hosts reporting. If you are building something new, jump to the Modern equivalents section below for supported alternatives like Prometheus Node Exporter, Zabbix, and Datadog.

What the up.time agent does and why port 9998 matters

The up.time monitoring model is agent-based and pull-driven. A central monitoring station periodically connects to each Linux host, asks the local agent for metrics (CPU, memory, disk, network, processes), and stores the results. The agent itself does not run as a long-lived network daemon. Instead it is launched on demand by xinetd, the extended Internet services super-daemon, every time the station opens a connection.

That design has three practical consequences you must plan for:

• Port 9998/TCP must be open and listening on the agent host. This is the single port the station talks to.
• xinetd (or inetd) must be installed and running, because it is what actually spawns the agent binary per request.
• A dedicated service account (commonly uptagent) is created to own the agent files and run the collection scripts with least privilege.

Prerequisites before you install the up.time agent on Linux

Confirm these items up front. Missing any one of them is the most common cause of a "successful" install that never actually reports data.

• Root access: log in with your normal account, then elevate. The agent RPM creates users and writes to /opt, so it needs root.
• The agent RPM: the package named like uptimeagent-linux-5.1.312-x86_64.rpm, matching your CPU architecture (x86_64 here) and the major version of your monitoring station.
• xinetd present: verify with rpm -q xinetd. Install it with yum install xinetd (RHEL/CentOS 6/7) or dnf install xinetd (RHEL/Rocky/Alma 8+) if it is absent.
• Core utilities: the agent shells out to sed, awk, netstat, vmstat, df, which, join, date and uname. On minimal images install net-tools (for netstat) and procps-ng (for vmstat).
• Firewall plan: know whether firewalld, iptables, and/or TCP wrappers (hosts.allow/hosts.deny) are in play, because each must allow the station's IP on 9998.

Step-by-step: install and configure the up.time agent on Linux

The original vendor notes contained a couple of small but breaking typos (a missing leading slash on a path, and a privilege command that does not elevate). The corrected, reliable sequence is below.

1. Log in and become root. Connect with your domain or local account, then switch to root with a login shell so the environment is correct:
   sudo -i
   or, if you already know the root password, su -. (Note: sudo su - from older notes also works, but sudo -i is the clean modern form. Plain su without the dash is wrong here because it keeps your old environment.)
2. Go to the directory holding the installer. Use an absolute path with the leading slash — the legacy cd home/Install/Uptime is a relative path and fails from anywhere but /:
   cd /home/Install/Uptime
   If that directory does not exist, create it and copy the RPM there from your trusted internal repository or media. Verify the file is present and uncorrupted before installing:
   ls -l uptimeagent-linux-5.1.312-x86_64.rpm
3. Install the RPM. The -i flag installs, -v is verbose, and -h prints a hash progress bar:
   rpm -ivh uptimeagent-linux-5.1.312-x86_64.rpm
   A correct run prints a series of post-install steps: creating the uptagent user, extracting files to /opt/uptime-agent, registering the agent as an xinetd service, restarting xinetd, confirming port 9998 is open, and checking each required utility. The final line is "Agent installation complete."
4. Open the firewall for port 9998. The RPM only configures the service; it does not punch through your host firewall. On firewalld systems:
   firewall-cmd --permanent --add-port=9998/tcp
firewall-cmd --reload
   On older iptables systems, allow it only from the monitoring station's IP for safety:
   iptables -A INPUT -p tcp -s <station_ip> --dport 9998 -j ACCEPT
5. If TCP wrappers are in use, allow the agent. When the host uses tcpd/TCP wrappers to gate connections, the agent will silently refuse the station until you whitelist it. Add a line to /etc/hosts.allow and then restart the super-daemon:
   uptmagent: <station_ip>
systemctl restart xinetd
   (On very old SysV hosts use service xinetd restart instead.)
6. Ensure xinetd survives reboots. The agent is useless if its super-daemon does not start at boot:
   systemctl enable --now xinetd

How the install actually works under the hood

Understanding what the RPM did makes troubleshooting far easier. After a clean install you will find:

• A service definition in /etc/xinetd.d/ (typically named uptmagent) that maps port 9998 to the agent binary, sets the run-as user, and controls per-source access.
• The agent payload under /opt/uptime-agent, including a README.txt with version-specific notes and the collection scripts.
• The service account uptagent, created without an interactive login, used to run the metric-collection commands with limited privilege.
• An entry in /etc/services mapping the symbolic service name to 9998/tcp so xinetd can resolve it.

Because the agent is spawned per connection, you will not see a persistent uptmagent process in ps when idle. You will only see xinetd itself listening. That is expected behavior, not a fault.

Verifying the up.time agent on Linux is running correctly

Do not trust the installer's "complete" message alone. Run these three independent checks. Each one validates a different layer of the stack.

1. Confirm the super-daemon is alive. Since the agent runs under xinetd, the daemon must be up:
   ps -ef | grep xinetd
   You should see a line such as root 20450 1 0 10:41 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid. The trailing grep xinetd line is just your own command and can be ignored. A cleaner check that avoids that noise is pgrep -a xinetd.
2. Confirm port 9998 is listening. Verify the socket is bound and in LISTEN state:
   netstat -nap | grep 9998
   Expected output resembles tcp 0 0 0.0.0.0:9998 0.0.0.0:* LISTEN 20450/xinetd — note the listening process is xinetd, which is correct. If netstat is missing on a modern minimal host, use the supported replacement:
   ss -lntp | grep 9998
3. Test the response end to end. Simulate what the monitoring station does by opening the port from another machine (ideally the station itself):
   nc -zv <agent_host> 9998
   A succeeded result means the firewall, TCP wrappers, xinetd, and the agent binary are all cooperating. Only after this passes should you add the host in the monitoring station console.

Common pitfalls and how to fix them

These are the failures that trip up most administrators, with the fix for each.

• Relative path error. Running cd home/Install/Uptime from your home directory throws No such file or directory. Always use the absolute path /home/Install/Uptime.
• Not actually root. The RPM aborts when it cannot create the uptagent user or write to /opt. Confirm with whoami returning root before installing.
• xinetd not installed. The post-install "Restarting (x)inetd" step fails or warns. Install it (yum install xinetd / dnf install xinetd), then re-run the agent install or simply systemctl restart xinetd.
• Port reachable locally but not remotely. Almost always the host firewall or TCP wrappers. Re-check firewall-cmd --list-ports, your iptables rules, and /etc/hosts.allow. The agent binding to 0.0.0.0:9998 only proves the local listener exists, not that traffic is permitted in.
• SELinux blocking the bind. On enforcing systems an unusual service port can be denied. Check getenforce and inspect ausearch -m avc -ts recent. If needed, label the port with semanage port -a -t inetd_child_port_t -p tcp 9998 (install policycoreutils-python-utils first).
• Missing utilities on minimal images. The dependency check reports a tool as not found. Install net-tools (netstat) and procps-ng (vmstat), then reinstall so the agent re-detects them.
• Stale previous agent. If an older agent ran in standalone daemon mode, stop and remove it first (rpm -e uptimeagent) so the new install registers cleanly under xinetd.

Quick command reference

Modern equivalents for new deployments

Because the up.time product is discontinued, do not build new monitoring on it. The same goals — installing a Linux monitoring agent, exposing metrics on a port, and verifying reachability — are met today by these supported tools:

• Prometheus + Node Exporter: the de facto open-source standard. Node Exporter exposes host metrics on port 9100, and Prometheus scrapes them. Same pull model, far richer metrics, huge ecosystem.
• Zabbix Agent: the closest direct analog. The Zabbix agent listens on port 10050, the server polls it, and it supports both passive (pull) and active (push) modes.
• Datadog / New Relic agents: SaaS options that push metrics outbound over HTTPS, removing the need to open an inbound port at all.
• Netdata: a lightweight, single-binary agent with a real-time dashboard out of the box, ideal for quick per-host visibility.

The transferable skills are identical: package the agent, run it under a least-privilege user, control its listening port, and validate connectivity with ss and nc before trusting the dashboard.

Key Takeaways

• The up.time agent is spawned on demand by xinetd on TCP port 9998, so xinetd must be installed, running, and enabled at boot.
• Install as root with rpm -ivh, and always use the absolute path to the installer to avoid the classic relative-path failure.
• Verify in three layers: xinetd alive, port 9998 listening, and a remote nc test from the monitoring station.
• A reachable local socket does not equal remote access — check the firewall, TCP wrappers, and SELinux.
• up.time is end-of-life; for new builds use Prometheus Node Exporter, Zabbix, Datadog, or Netdata instead.

Frequently Asked Questions

Why is there no up.time agent process when I run ps?

That is normal. The agent is not a persistent daemon — xinetd launches it only when the monitoring station connects, then it exits. When idle you will only see the xinetd process listening on port 9998. Use ss -lntp | grep 9998 to confirm the listener is bound.

What port does the up.time Linux agent use?

It listens on TCP port 9998. The monitoring station initiates connections to that port on each agent host, so it must be open in the host firewall and, where applicable, in /etc/hosts.allow for the station's IP.

How do I install xinetd if it is missing?

On RHEL/CentOS 6 or 7 run yum install xinetd; on RHEL, Rocky, or AlmaLinux 8 and later run dnf install xinetd. Then enable and start it with systemctl enable --now xinetd before reinstalling or restarting the agent.

Is up.time still supported, and what should I use instead?

No. The product was acquired and discontinued, so 5.x agents are end-of-life and receive no updates. For new monitoring, deploy Prometheus with Node Exporter, Zabbix, Datadog, or Netdata, all of which are actively maintained and follow the same agent-and-port pattern.

For more Linux and system-administration walkthroughs, subscribe to @explorenystream on YouTube.