Linux
RHEL-based application servers, systemd service control, process and port analysis, shell administration, patching, certificates, and log-driven troubleshooting.
Archive 03 · Operating systems
Systems
Archive
A server is not healthy because it responds to ping, a service is not healthy because it says “running,” and a change is not complete until the application is proven from the outside.
- 01HOSTreachable
- 02DEPENDENCIESready
- 03SERVICESactive
- 04LISTENERSverified
- 05IDENTITYcurrent
- 06APPLICATIONproven
› Maintenance complete only when layer 06 passes._
Engineering perspectiveAdminister · diagnose · recover
Beyond the operating system
Platform health is the beginning
of validation—not the end.
Christian’s systems work spans Linux and Windows application servers, VMware environments, service dependencies, certificates, patching, backups, upgrades, migrations, and after-hours production maintenance.
The objective is never merely to run a command or clear an alarm. It is to understand the system’s state, make the safest effective change, and prove that the dependent service recovered.
Platform coverage
Different consoles. Same discipline.
Tools and syntax change by platform, but the engineering questions remain consistent: what started, what it depends on, what it exposes, and whether users can reach it.
Windows Server
Windows services, Event Viewer, IIS bindings, MMC certificate stores, networking, scheduled tasks, updates, and application dependencies.
Virtualization
Guest resources, snapshots, backups, templates, tools, time synchronization, migrations, power operations, and rollback planning.
Service anatomy
“Running” is one data point
A status command reports what the service manager believes. Application health requires corroborating evidence across the entire stack.
- 01
Process
Is the expected process running under the expected account?
- 02
Dependency
Did databases, directories, mounts, DNS, time, and upstream services become ready first?
- 03
Socket
Is the service listening on the correct address and port—and is the intended process holding it?
- 04
Configuration
Which file, registry value, binding, environment variable, or startup argument is actually active?
- 05
Identity
Which account, certificate, key, trust chain, and permissions are in use?
- 06
Evidence
What do application, system, security, and platform logs show at the exact failure time?
Evidence catalog
Commands answer questions.
They are not the investigation.
Choose the smallest command set that can confirm or eliminate a hypothesis. Preserve timestamps and output, then compare the result with the pre-change baseline.
systemctl status · journalctl · ss -lntup · ps · df · freeService state, recent failures, listeners, processes, storage, and memory.
Get-Service · Get-WinEvent · Get-NetTCPConnectionService state, event evidence, and active listeners or connections.
openssl s_client · keytool · certutil · PowerShell Cert:What is stored, what is bound, and what a remote client is actually receiving.
Guest state · console · tasks/events · tools · datastorePlatform health, recent changes, guest communication, and storage conditions.
Controlled change
Maintenance is an evidence chain
The safe path includes preparation, execution, validation, observation, and a clear record of what happened—not only the technical step in the middle.
- 01
Baseline
Capture version, uptime, service state, listeners, resource use, alarms, dependencies, and current user-facing behavior.
- 02
Protect
Confirm backups, configuration exports, snapshots only where appropriate, access, console availability, and an executable backout.
- 03
Change
Follow the approved sequence, timestamp actions, preserve output, and stop when an unexpected condition changes the risk.
- 04
Validate
Prove platform health, service state, dependencies, ports, certificates, application behavior, and external connectivity.
- 05
Observe
Allow enough time for reconnects, delayed alarms, scheduled jobs, replication, and dependent applications to settle.
- 06
Close
Record results, exceptions, evidence, remaining risk, ownership, and the precise state left for operations.
Sanitized field patterns
What the first check can miss
These patterns come from production work where the visible administrative state and the service users actually received were not the same thing.
The new certificate exists, but the old one is still presented
The certificate store is only one layer. Verify the active IIS binding, application keystore or alias, service configuration, and whether a restart is required. Test the remote port—not just the local store.
The service says active, but users still cannot connect
A running parent process does not prove a healthy application. Confirm listeners, dependencies, logs, local transactions, remote transactions, and client reconnection.
A replacement VM is ready, but cutover risk remains
Validate backups and data migration, record addressing and licensing dependencies, test the new guest, and keep the original system available as a defined rollback path.
Repeatable operations
Automate the collection.
Keep judgment with the engineer.
Post-maintenance validation concept
- Service status and uptime
- OS and package versions
- Disk and memory condition
- Listening ports
- Recent critical log events
- Certificate identity and expiration
Python, PowerShell, and Bash can gather consistent evidence. The engineer still determines whether the evidence proves the service is ready.
Systems doctrine
State is not service
Healthy infrastructure is measured from the consumer’s side. Validate the platform, then validate the workload, the network path, the identity presented, and every critical dependency.
Return to all archives →