Use Logwatch to Monitor Ubuntu System Logs

Logwatch is a compact Perl utility that turns busy system logs into a short, readable report. Understanding how to use Logwatch for monitoring system logs on Ubuntu helps everyday users notice failed sign-ins, service restarts, package changes and kernel warnings without reading every file in /var/log by hand. It is a reporting tool rather than a live security monitor.

A typical report groups entries by service and separates important lines from routine activity. That makes it useful on a family desktop, home server, Raspberry Pi or Ubuntu development laptop. The same summary can show whether a VPN disconnected repeatedly, unattended upgrades ran, or storage and memory errors appeared after boot.

Ubuntu’s systemd setup introduces one important detail: many recent events live in the systemd journal, while Logwatch traditionally reads plain-text files. Some Ubuntu installations also maintain copies in /var/log/syslog and /var/log/auth.log. The relevant source must exist before Logwatch can summarise it.

The workflow below covers installation, first use, configuration, scheduling and diagnosis. Commands prefixed with sudo require administrator rights. Reports may contain IP addresses, hostnames and usernames, so they should be handled as private system records.

Install Logwatch on Ubuntu

Open a terminal and run sudo apt update, followed by sudo apt install logwatch. Logwatch is normally available in Ubuntu’s universe repository on current Desktop and Server releases. If APT reports that no candidate exists, enable that repository with sudo add-apt-repository universe, repeat the update and try the installation again.

The first installation may ask whether reports should be emailed and whether the generated configuration should be retained. Choose the email option only if a working mail system is already available. For an initial local trial, declining email delivery is sensible; retaining the configuration file ensures that later manual runs use the package defaults.

Logwatch needs permission to read restricted logs such as authentication records. Installing it does not grant remote access or open a network port. Its main privilege comes from reading system files and, when configured, invoking the local mail service to deliver reports.

Run and Read a First Report

Run sudo logwatch --output stdout --range yesterday to send the report to the terminal instead of email. The default range can cover a broader period, so specifying yesterday makes the first result easier to understand. Use sudo logwatch --output stdout --range today when investigating a current incident.

Entries mentioning an accepted SSH login, a clean shutdown or an installed package are often normal. Warnings become more significant when they repeat, mention a failed password, report a service restart loop, indicate filesystem corruption or expose kernel hardware errors. Logwatch extracts patterns from text; it does not decide whether an event is malicious.

When email delivery is disabled, Logwatch normally saves reports under /var/log/logwatch. Use sudo less /var/log/logwatch to browse saved files. Do not publish these reports without checking them, since authentication logs can reveal user names, network addresses and the names of services running on the machine.

Adjust the Main Logwatch Settings

The main configuration file is /etc/logwatch.conf. Create a backup with sudo cp /etc/logwatch.conf /etc/logwatch.conf.bak, then open it using sudoedit /etc/logwatch.conf. Keeping the package default available makes it easier to compare behaviour after an edit.

Common settings include LOGWATCH_WEEKDAY, which affects dated or scheduled output, and LOGWATCH_DETAIL, which controls how much matching text appears. Other options control date headings, separators and the email destination. A setting such as LOGWATCH_DETAIL = Medium provides more context without producing every matching line at the highest detail level.

Cron schedules and Logwatch report dates use the system’s local time. That matters across Australia: Brisbane uses Australia/Brisbane without daylight saving, while Sydney and Melbourne use Australia/Sydney and Australia/Melbourne with seasonal clock changes. Keep the selected IANA time zone correct, especially on a laptop that moves between Australian cities or is configured manually rather than through automatic location detection.

Select Logs and Reporting Detail

Begin by checking which traditional log files exist and are readable:

ls -l /var/log/syslog /var/log/auth.log /var/log/apt/history.log

A missing file is not automatically a problem. Authentication events may exist only in the journal, auth.log may be absent when rsyslog is not installed, and some Ubuntu Server installations use a different logging arrangement. journalctl can confirm whether a recent event exists even when Logwatch has no corresponding text source.

Additional configurations can be placed as Perl-style blocks in .conf files under /etc/logwatch/conf.d. For example, this block directs Logwatch towards the APT history:

MyPackageReview = {
    LogFile = "/var/log/apt/history.log"
    Detail = Medium
};

Use separate, clearly named blocks for separate files. Detail levels range from brief summaries to extensive matches, while service-specific scripts can recognise particular applications. Review custom scripts before enabling them because an incorrect regular expression may either hide important entries or flood the report with routine ones.

Account for systemd Journal Logs

The systemd journal normally stores structured records in /var/log/journal or /var/log/journal/*, and its binary format is not a direct Logwatch input. A quick warning-level check can be performed with:

journalctl --since yesterday --priority warning --no-pager

This shows whether relevant activity exists even when Logwatch produces an empty report.

An optional approach is to install rsyslog, which writes selected journal events to traditional text files:

sudo apt install rsyslog
sudo systemctl enable --now rsyslog

Afterwards, check that /var/log/syslog or /var/log/auth.log exists and decide whether Logwatch should scan those files or the journal-derived alternatives. Avoid monitoring duplicate representations unnecessarily, and retain normal log rotation because text copies consume disk space. Mobile Ubuntu has similar source-selection issues; this Fairphone 5 first look offers context for Logwatch outside a conventional desktop.

Schedule Reports and Choose Delivery

Logwatch packages commonly include a daily job such as /etc/cron.daily/logwatch, although the exact file can be checked with ls -l /etc/cron.daily/logwatch. Retain only one scheduler. For a specific time, run command -v logwatch, open sudo crontab -e and add a line using the displayed path:

30 7 * * * /usr/bin/logwatch --range yesterday

Replace /usr/bin/logwatch if command -v returns another location. Cron uses the configured Australian time zone, but a suspended laptop may miss the scheduled run. Daily rules also fire during weekends and Australian public holidays, so select a report time that suits the normal reading routine.

File delivery under /var/log/logwatch is the simplest option for an Ubuntu desktop. For email, set the address in /etc/logwatch.conf, normally with LOGWATCH_EMAIL, and ensure a local mail transfer agent can send the message. Australian broadband providers such as Telstra or Optus may require authenticated SMTP or restrict outbound port 25 for connections delivered over services such as NBN. Provider-approved authenticated relaying is more reliable than direct delivery, and passwords should never be placed directly in the Logwatch configuration.

Troubleshoot and Build a Baseline

Run sudo logwatch --debug --output stdout --range yesterday when a command fails silently or produces an incomplete report. Debug output reveals the configuration files, watched logs and date range being used, although it may also display sensitive paths and event data. Remove debug mode after the cause is identified.

An empty report usually means that the selected range contains no matching entries, the expected text log is absent, or the watched file contains only journald data. Confirm the files with ls -l /var/log, inspect the journal with journalctl and review any custom definitions in /etc/logwatch/conf.d. If both a packaged cron job and a root crontab entry run Logwatch, repeated output is likely.

To remove the utility, use sudo apt purge logwatch. APT will indicate which configuration files remain, and any retained reports should be reviewed before deletion. If custom definitions contain useful service knowledge, archive them first rather than allowing a later package change to remove them silently.

A first report is most useful as a baseline for recognising changes in normal activity. The concrete next step is to run sudo logwatch --output stdout --range yesterday on the Ubuntu system you want to understand first.