Guix provides a service to perform unattended upgrades: periodically, the system automatically reconfigures itself from the latest Guix. Guix System has several properties that make unattended upgrades safe:
guix system list-generations—and you can roll back to any previous generation, should the upgraded system fail to behave as intended;
guix system reconfigureprevents downgrades, which makes it immune to downgrade attacks.
To set up unattended upgrades, add an instance of
unattended-upgrade-service-type like the one below to the list of
your operating system services:
The defaults above set up weekly upgrades: every Sunday at midnight. You do not need to provide the operating system configuration file: it uses /run/current-system/configuration.scm, which ensures it always uses your latest configuration—see provenance-service-type, for more information about this file.
There are several things that can be configured, in particular the
periodicity and services (daemons) to be restarted upon completion. When
the upgrade is successful, the service takes care of deleting system
generations older that some threshold, as per
delete-generations. See the reference below for details.
To ensure that upgrades are actually happening, you can run
system describe. To investigate upgrade failures, visit the unattended
upgrade log file (see below).
This is the service type for unattended upgrades. It sets up an mcron job
(see Запланированное исполнения задач) that runs
reconfigure from the latest version of the specified channels.
Its value must be a
unattended-upgrade-configuration record (see
This data type represents the configuration of the unattended upgrade service. The following fields are available:
"30 01 * * 0")
This is the schedule of upgrades, expressed as a gexp containing an mcron job schedule (see mcron job specifications in GNU mcron).
This gexp specifies the channels to use for the upgrade (see Каналы).
By default, the tip of the official
guix channel is used.
This field specifies the operating system configuration file to use. The default is to reuse the config file of the current configuration.
There are cases, though, where referring to
/run/current-system/configuration.scm is not enough, for instance
because that file refers to extra files (SSH public keys, extra
configuration files, etc.) via
local-file and similar
constructs. For those cases, we recommend something along these lines:
(unattended-upgrade-configuration (operating-system-file (file-append (local-file "." "config-dir" #:recursive? #t) "/config.scm")))
The effect here is to import all of the current directory into the store,
and to refer to config.scm within that directory. Therefore, uses of
local-file within config.scm will work as expected.
See G-Expressions, for information about
This field specifies the Shepherd services to restart when the upgrade completes.
Those services are restarted right away upon completion, as with
herd restart, which ensures that the latest version is
running—remember that by default
guix system reconfigure only
restarts services that are not currently running, which is conservative: it
minimizes disruption but leaves outdated services running.
herd status to find out candidates for restarting.
See Сервисы, for general information about services. Common services to
restart would include
By default, the
mcron service is restarted. This ensures that the
latest version of the unattended upgrade job will be used next time.
(* 3 30 24 3600))
This is the expiration time in seconds for system generations. System
generations older that this amount of time are deleted with
system delete-generations when an upgrade completes.
Примечание: The unattended upgrade service does not run the garbage collector. You will probably want to set up your own mcron job to run
Maximum duration in seconds for the upgrade; past that time, the upgrade aborts.
This is primarily useful to ensure the upgrade does not end up rebuilding or re-downloading “the world”.
File where unattended upgrades are logged.