Skip to content

Knowledgebase

Inspecting Linux logs through Webmin

control-panels, servers

Use Webmin logs to connect a visible failure with the service and timestamp that produced it. System logs, systemd journals, Virtualmin domain logs and application logs are separate evidence sources.

What you need before you begin

Record the failed action, hostname, response and approximate time with timezone. Confirm your authorization to view logs because they can include customer addresses, paths and other private data. Avoid copying complete logs into a public support channel.

01 Inspect Linux logs through Webmin

  1. For a system service, open the applicable System Logs view or its journal view under Systemd Services and Units. Locate entries around the incident rather than searching only for the word error across every file.
  2. Filter by service or unit when possible. Read the messages immediately before the failure to distinguish the original cause from later restart or connection errors.
  3. For a hosted website, select the Virtualmin domain and inspect its access and error logs. Check application-private logs when the web server only reports an upstream failure.
  4. Reproduce one safe request while observing the relevant log, if doing so will not duplicate a payment, email campaign or destructive job. Match request time and path.
  5. Record the first actionable cause, such as permission denial, missing dependency, database failure or exhausted resource. Apply one justified correction and repeat the same harmless test.
  6. Preserve a short sanitized incident excerpt and resolution before routine rotation removes the useful evidence.

Why is the usual log file missing?

The service may log to systemd journal, a different configured file or a container destination. Inspect the active service configuration instead of creating an empty file and assuming messages will appear there.

Confirm the expected result

Confirm the expected successful operation appears and the matching failure stops recurring. Verify logging still works after any configuration change. If the original problem is intermittent, monitor through a representative workload period.

Troubleshoot unexpected results

If no relevant entry appears, check the configured log destination, journal permissions and whether traffic reaches this machine. Do not expose detailed PHP errors publicly or make private logs world-readable. Use a protected export when another administrator needs evidence.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support