It’s much easier to update a server on time than to deal with the consequences of a breach later on. Often, the cause of many successful attacks isn’t sophisticated techniques used by attackers, but rather a simple disregard for basic information and cybersecurity hygiene. For example, a patch for a vulnerability was released several weeks or months ago, yet the server continues to run an old version of the software that is vulnerable to attack.
Even a minimal Ubuntu installation consists of dozens of separate components, such as the system kernel itself, SSH, a web server, libraries, language interpreters, administration tools, and so on. All of these receive regular updates.
However, not every system update results in downtime, as Ubuntu Server can automatically install security patches, and some kernel updates can be applied without a reboot at all thanks to Livepatch technology - which is very useful for servers where downtime is critical.
This approach is particularly convenient if the server hosts websites, CRMs, APIs, email services, databases, or internal company services that, whenever possible, should not be restarted. Again, the administrator has fewer routine tasks to perform, and the window of opportunity during which the system can be attacked via a known vulnerability becomes significantly shorter.
Once a new vulnerability is disclosed, there’s usually little time to secure the server, as Internet scans begin almost immediately, and automated bots quickly find servers whose owners have decided to postpone the update for one reason or another. As a result, the longer the installation of patches is delayed, the higher the likelihood that the vulnerability will be exploited.
Automatic Installation of Updates
The task of automatically installing updates in Ubuntu has long been handled by built-in tools. This is managed by the unattended-upgrades package, which automatically checks for updates, downloads them, and installs them without administrator intervention.
Installing this package takes a couple of minutes and is done with the following commands:
sudo apt update
sudo apt install unattended-upgrades
After that, you should run the configuration wizard:
sudo dpkg-reconfigure unattended-upgrades
During configuration, the system will ask whether you want to automatically install security updates. In most cases, it makes sense to select Yes.
Where to Find the Settings
The behavior of the unattended-upgrades utility is defined by two files.
The first file is /etc/apt/apt.conf.d/50unattended-upgrades. This file specifies which updates are allowed to be installed automatically. In this same file, you can change additional settings, such as:
- the list of repositories used;
- automatic removal of dependencies that are no longer needed;
- clearing the package cache;
- sending email notifications;
- automatic reboot after installing updates.
The configuration is thoroughly commented, so figuring out the settings will be quite simple.
The second file is /etc/apt/apt.conf.d/20auto-upgrades. It controls the frequency of the process. The most common configuration example might look like this:
APT::Periodic::Update-Package-Lists “1”;
APT::Periodic::Unattended-Upgrade “1”;
This configuration means the following:
- Update-Package-Lists - update the package list daily;
- Unattended-Upgrade - install permitted updates daily.
If desired, you can change the schedule. For example, you can run automatic updates every few days instead of daily.
How to Check If the Mechanism Is Working
After setting up automatic updates, it’s a good idea to make sure everything is actually working as intended. To do this, first check the status of the main service using the command:
systemctl status unattended-upgrades
Next, check the update log:
cat /var/log/unattended-upgrades/unattended-upgrades.log
Or use the systemd journal:
journalctl -u unattended-upgrades
If the mechanism is working properly, the logs will show downloaded packages, installed updates, and any errors that occurred during installation.
When a Reboot Is Needed - and When It Isn’t
There’s a common misconception that a Linux server must be rebooted after every update. But this isn’t true at all, since most packages are updated without stopping the operating system. After installing a new version, it’s usually sufficient to restart only the service that uses the updated files.
For example, after updating the Nginx web server, you can simply run the command:
sudo systemctl reload nginx
or after updating PostgreSQL, run:
sudo systemctl restart postgresql
For users of your website or application, these actions usually go unnoticed.
The opposite situation occurs when updating the Linux kernel itself. The new version is installed on the disk, but the server continues to run on the old kernel, which is already in RAM. Therefore, the changes will not take effect until the system is rebooted.
This is precisely why, after certain updates, Ubuntu displays the message:
System restart required
A reboot may also be required after updating certain system components that cannot be replaced "on the fly". These typically include components such as:
- systemd;
- glibc;
- hardware drivers;
- processor microcode;
- and certain virtualization components.
In all other cases, it is sufficient to restart only the necessary services without affecting the operation of the entire server. This allows most updates to be installed without significant downtime.
Canonical Livepatch
To reduce the number of reboots, Canonical developed Livepatch technology. It allows many critical security patches to be applied directly to the running Linux kernel, without shutting down the system or restarting the server.
As we learned earlier, after a kernel update, the new version takes effect only after the server is rebooted. But Livepatch ensures that, for supported vulnerabilities, patches are loaded into memory and applied to the running kernel. As a result, the server continues to serve users, and no unscheduled maintenance window is required.
To use this technology, you’ll need an Ubuntu One account. After registering, simply install the Livepatch client on your server, link the server to your account, and activate the service. Subsequent installation of supported patches occurs automatically in the background.
Livepatch is most beneficial in scenarios where even a brief outage is undesirable. For example:
- VPS with high availability requirements;
- production web servers;
- database servers;
- enterprise applications;
- cloud infrastructure.
However, it’s important to understand that Livepatch’s capabilities are not unlimited. This technology applies only to certain kernel security patches and does not replace full system updates. Therefore, if a new kernel version is released, its internal mechanisms change, or major functional updates are installed, a scheduled server reboot is still necessary. This is precisely why Livepatch should be viewed as a way to reduce the number of server reboots, rather than as a way to eliminate them entirely.
How to Tell If a Reboot Is Needed
After installing certain updates, Ubuntu automatically creates a special marker file. Its presence indicates that some of the installed changes will only take effect after the system is rebooted.
You can check for the existence of this file using the command:
test -f /var/run/reboot-required && echo “Reboot required”
or simply:
ls /var/run/reboot-required
If the file exists, you shouldn’t put off the reboot indefinitely. The server itself will continue to run, but the updated kernel or certain system components will remain inactive until the next reboot.
In large infrastructures, this mechanism is often used in conjunction with monitoring systems and configuration management tools that automatically track the appearance of the reboot-requiredfile, notify administrators, and help plan server maintenance without the need for constant manual checks.
How to Identify Processes Using Outdated Libraries
After updating libraries, some services continue to use the previously loaded versions of the files. Until the process is restarted, the changes will not take effect.
The needrestart utility helps verify this.
To install this utility, run the command:
sudo apt install needrestart
Run the utility with the command:
sudo needrestart
After analysis, the program will display:
- services that should be restarted;
- the need for a full reboot;
- processes that continue to use old versions of libraries.
In many cases, this is sufficient to avoid unnecessary reboots and limit the process to restarting individual services.
Practical Recommendations
Automatic installation of updates relieves the administrator of a significant amount of routine work, but it’s still not advisable to leave the server completely unmonitored. Even reliable mechanisms like unattended-upgradesshould be checked from time to time, especially if the system supports active projects.
Before enabling automatic updates, it is advisable to:
- set up backups;
- test updates on a test server if critical infrastructure is involved;
- periodically review the
unattended-upgradeslogs; - monitor the need for reboots;
- monitor the status of services after updates are installed;
- manually perform a full system update from time to time.
Using monitoring is also considered a best practice. If, after installing updates, a service stops responding or a reboot is required, the administrator will find out about it immediately, rather than several hours or days later.
For VPS and dedicated servers with high workloads, it makes sense to plan maintenance windows in advance. Most updates will install automatically and without downtime; however, kernel updates, service health checks, or other administrative tasks are still best performed according to a pre-agreed schedule.
FAQ or Frequently Asked Questions
Is it possible to completely eliminate manual updates?
For most small servers, this is entirely feasible. However, if the infrastructure is business-critical, it’s best to periodically check it manually, monitor the status of services, and review logs after installing updates.
How secure are automatic updates?
Security updates are tested before release, so the likelihood of problems is low. Nevertheless, backups should remain a mandatory part of any server infrastructure.
Should absolutely all packages be updated automatically?
Not always. Many administrators allow only security updates to be installed automatically, while functional changes and upgrades to new software versions are performed during scheduled maintenance.
Can automatic updates be temporarily disabled?
Yes. This is sometimes done before major infrastructure changes, service migrations, or application updates. Once the work is complete, it’s best to re-enable automatic updates so the server doesn’t remain without the latest security patches.
Does Livepatch replace a regular kernel update?
No. Livepatch installs only a subset of critical security patches for supported kernel versions. However, full kernel updates and scheduled reboots are still necessary.
How often should you check the automatic update logs?
If the server is running stably, it’s usually sufficient to review the logs once every few weeks or after receiving notifications from the monitoring system. On servers with high workloads or critical services, log monitoring is often included in regular scheduled checks.
Conclusions
Ubuntu Server’s automatic updates allow you to keep the system up to date without constant administrator intervention. The unattended-upgrades package automatically installs approved updates, needrestart helps determine which services require a restart, and Canonical Livepatch, in some cases, allows you to avoid a reboot even after kernel vulnerabilities have been patched.
However, it is still not possible to completely relinquish control. Backups, monitoring, log checks, verifying the need for reboots, and scheduled maintenance windows remain an integral part of operating any server.
As a result, administrators spend less time on routine tasks, and the server receives security patches more quickly. For VPS, dedicated servers, and any modern infrastructure, this approach has long been standard practice, so you should also consider implementing this mechanism in your infrastructure - taking into account, of course, all the practical recommendations we’ve provided.
