Browsing Catalan translation

82.

The save command creates a snapshot of the current user, system and
configuration data for the given snaps.

By default, this command saves the data of all snaps for all users.
Alternatively, you can specify the data of which snaps to save, or
for which users, or a combination of these.

If a snap is included in a save operation, excluding its system and
configuration data from the snapshot is not currently possible. This
restriction may be lifted in the future.

83.

The saved command displays a list of snapshots that have been created
previously with the 'save' command.

84.

The services command lists information about the services specified, or about
the services in all currently installed snaps.

85.

The services command lists information about the services specified.

86.

The set command changes the provided configuration options as requested.

$ snap set snap-name username=frank password=$PASSWORD

All configuration changes are persisted at once, and only after the
snap's configuration hook returns successfully.

Nested values may be modified via a dotted path:

$ snap set snap-name author.name=frank

Configuration option may be unset with exclamation mark:
$ snap set snap-name author!

87.

The set command sets the provided configuration options as requested.

$ snapctl set username=frank password=$PASSWORD

All configuration changes are persisted at once, and only after the hook
returns successfully.

Nested values may be modified via a dotted path:

$ snapctl set author.name=frank

Configuration option may be unset with exclamation mark:
$ snapctl set author!

Plug and slot attributes may be set in the respective prepare and connect hooks
by naming the respective plug or slot:

$ snapctl set :myplug path=/dev/ttyS0

88.

The set-health command is called from within a snap to inform the system of the
snap's overall health.

It can be called from any hook, and even from the apps themselves. A snap can
optionally provide a 'check-health' hook to better manage these calls, which is
then called periodically and with increased frequency while the snap is
"unhealthy". Any health regression will issue a warning to the user.

Note: the health is of the snap only, not of the apps it contains; it’s up to
the snap developer to determine how the health of the individual apps is
reflected in the overall health of the snap.

status can be one of:

- okay: the snap is healthy. This status takes no message and no code.

- waiting: a resource needed by the snap (e.g. a device, network, or service) is
not ready and the user will need to wait. The message must explain what
resource is being waited for.

- blocked: something needs doing to unblock the snap (e.g. a service needs to be
configured); the message must be sufficient to point the user in the right
direction.

- error: something is broken; the message must explain what.

89.

The set-quota command updates or creates a quota group with the specified set of
snaps.

A quota group sets resource limits on the set of snaps or snap services it contains.
Snaps can be at most in one quota group but quota groups can be nested. Nested quota
groups are subject to the restriction that the total sum of each existing quota
in sub-groups cannot exceed that of the parent group the nested groups are part of.

All provided snaps are appended to the group; to remove a snap from a
quota group, the entire group must be removed with remove-quota and recreated
without the snap. To remove a sub-group from the quota group, the
sub-group must be removed directly with the remove-quota command.

To set limits on individual services, one or more services can be placed into a
sub-group. The respective snap for each service must belong to the sub-group's
parent group. These sub-groups will have the same limitations as nested groups
which means their combined resource usage cannot exceed the resource limits set
for the parent group. Sub-groups which contain services cannot have their own
journal quotas set, and instead automatically inherit any journal quota their
parent quota group may have.

The memory limit for a quota group can be increased but not decreased. To
decrease the memory limit for a quota group, the entire group must be removed
with the remove-quota command and recreated with a lower limit. Increasing the
memory limit for a quota group does not restart any services associated with
snaps in the quota group.

The CPU limit for a quota group can be both increased and decreased after being
set on a quota group. The CPU limit can be specified as a single percentage which
means that the quota group is allowed an overall percentage of the CPU resources. Setting
it to 50% means that the quota group is allowed to use up to 50% of all CPU cores
in the allowed CPU set. Setting the percentage to 2x100% means that the quota group
is allowed up to 100% on two cpu cores.

The CPU set limit for a quota group can be modified to include new cpus, or to remove
existing cpus from the quota already set.

The threads limit for a quota group can be increased but not decreased. To
decrease the threads limit for a quota group, the entire group must be removed
with the remove-quota command and recreated with a lower limit.

The journal limits can be increased and decreased after being set on a group.
Setting a journal limit will cause the snaps in the group to be put into the same
journal namespace. This will affect the behaviour of the log command.

New quotas can be set on existing quota groups, but existing quotas cannot be removed
from a quota group, without removing and recreating the entire group.

Adding new snaps to a quota group will result in all non-disabled services in
that snap being restarted.

An existing sub group cannot be moved from one parent to another.

90.

The sign command signs an assertion using the specified key, using the
input for headers from a JSON mapping provided through stdin. The body
of the assertion can be specified through a "body" pseudo-header.

91.

The sign-build command creates a snap-build assertion for the provided
snap file.