this command moves processes defined by the list
of processes
(\fBpidlist\fR)
-to given control groups.
+to the given control groups.
The pids in the pidlist are separated by spaces
.TP
.B -g <controllers>:<path>
-defines control groups where the task will be moved.
+defines the control groups where the task will be moved.
\fBcontrollers\fR is a list of controllers and
\fBpath\fR is the relative path to control groups
in the given controllers list.
define multiple pairs of lists of controllers
and relative paths.
Instead of the list of all mounted controllers,
-wildcard \fB*\fR can be used.
+the wildcard \fB*\fR can be used.
If this option is not used then
-\fBcgclassify\fR will automatically place the task to the
+\fBcgclassify\fR will automatically move the task to a
control group based on \fB/etc/cgrules.conf\fR.
.TP
.B --sticky
-If this option is used, the daemon of service cgred (cgrulesengd
-process) does not change both the specified \fBpidlist\fR and their
-children tasks. Without this option, the daemon does not change the
-specified \fBpidlist\fR but it changes their children tasks to the
-right cgroup based on \fB/etc/cgrules.conf\fR automatically.
+If this option is used, the daemon of service cgred (cgrulesengd process)
+does not change both the specified \fBpidlist\fR and their children tasks.
+Without this option, the daemon does not change the specified \fBpidlist\fR
+but it automacically changes their child tasks to the right cgroup based on
+\fB/etc/cgrules.conf\fR.
.TP
.B --cancel-sticky
-If this option is used, the daemon of service cgred (cgrulesengd
-process) can change both the specified \fBpidlist\fR and their
-children tasks to right cgroup based on \fB/etc/cgrules.conf\fR
-automatically.
+If this option is used, the daemon of service cgred (cgrulesengd process)
+can automatically change both the specified \fBpidlist\fR and their child
+tasks to the right cgroup based on \fB/etc/cgrules.conf\fR.
.SH FILES
.LP
.SH DESCRIPTION
-This command moves all the tasks inside various cgroups
+This command moves all the tasks inside the various cgroups
to the root cgroup, deletes all the cgroups and finally
unmounts the cgroup filesystem from the system.
.B "cgconfig.conf"
is a configuration file used by
.B libcgroup
-to define control groups, their parameters and also mount points.
+to define control groups, their parameters and their mount points.
The file consists of
.I mount
and
.I group
sections. These sections can be in arbitrary order. Any line starting
-with '#' is considered as a comment line and is ignored.
+with '#' is considered a comment line and is ignored.
.LP
.I mount
section has this form:
.TP
.B controller
-Name of kernel subsystem. List of subsystems supported by kernel
+Name of the kernel subsystem. The list of subsystems supported by the kernel
can be found in
.I /proc/cgroups
file. Named hierarchy can be specified as controller
.TP
.B path
-The directory path, where group hierarchy associated to given
-controller, shall be mounted. The directory is created
+The directory path where the group hierarchy associated to a given
+controller shall be mounted. The directory is created
automatically on cgconfig service startup if it does not exist and
is deleted on service shutdown.
.LP
The root control group is always created automatically in all hierarchies
and it is the base of the group hierarchy. It can be explicitly specified in
.B cgconfig.conf
-file by using '.' as group name. This can be used e.g. to set its permissions,
+by using '.' as group name. This can be used e.g. to set its permissions,
as shown in Example 6.
-When the parent control group of a subgroup is not specified,
-then it is created automatically.
+When the parent control group of a subgroup is not specified
+it is created automatically.
.TP
.B permissions
.RS
.TP 17
.B "task user/group"
-Name of the user and the group, which owns
+Name of the user and the group, which own the
.I tasks
file of the control group. I.e. this user and members of this
-group has write access to the file.
+group have write access to the file.
.TP 17
.B "admin user/group"
-Name of the user and the group, which owns the rest of control group's
+Name of the user and the group which own the rest of control group's
files. These users are allowed to set subsystem
parameters and create subgroups.
.LP
-Permissions are related only to enclosing control group and are not
+Permissions are only apply to the enclosing control group and are not
inherited by subgroups. If there is no
.B perm
-section in control group definition,
+section in the control group definition,
.I root:root
-is owner of all files.
+is the owner of all files.
.RE
.TP
.B controller
.B controller
the control group and all its parents are controlled by the specific
subsystem. One control group can be controlled by multiple subsystems,
-even if the subsystems are mounted to different directories. Each
-control group must be controlled by at least one subsystem, so
+even if the subsystems are mounted on different directories. Each
+control group must be controlled by at least one subsystem, so that
.B libcgroup
-knows, in which hierarchies the control group should be created.
+knows in which hierarchies the control group should be created.
-The parameters of given controller can be modified in following section
-enclosed in brackets.
+The parameters of the given controller can be modified in the following
+section enclosed in brackets.
.RS
.TP
.B param name
parameters.
.TP
.B param value
-Value, which should be written to the file when the control group is
-created. Optionally it can be enclosed in double quotes `"', it can
-contain spaces and other special characters then.
+Value which should be written to the file when the control group is
+created. If it is enclosed in double quotes `"', it can contain spaces
+and other special characters.
.RE
.\"********************************************"
.fi
.RE
-creates the hierarchy controlled by two subsystems, with no groups
-inside. It corresponds to following operations:
+creates the hierarchy controlled by two subsystems with no groups
+inside. It corresponds to the following operations:
.LP
.RS
.nf
.fi
creates the hierarchy controlled by two subsystems with one group and
two subgroups inside, setting one parameter.
-It corresponds to following operations:
+It corresponds to the following operations:
.LP
.RS
.nf
.I daemons
group is created automatically when its first subgroup is
created. All its parameters have the default value and only root can
-access group's files.
+access the group's files.
.LP
Since both
.I cpuacct
and
.I cpu
subsystems are mounted to the same directory, all
-groups are implicitly controlled also by
+groups are implicitly also controlled by the
.I cpuacct
subsystem, even if there is no
.I cpuacct
.fi
.RE
creates two hierarchies and one common group in both of them.
-It corresponds to following operations:
+It corresponds to the following operations:
.LP
.RS
.nf
.fi
.RE
-In fact there are two groups created. One in
+In fact there are two groups created. One in the
.I cpuacct
-hierarchy, the second in
+hierarchy, the second in the
.I cpu
hierarchy. These two groups have nothing in common and can
contain different subgroups and different tasks.
}
.fi
.RE
-creates two hierarchies with few groups inside. One of groups
+creates two hierarchies with few groups inside. One of the groups
is created in both hierarchies.
-It corresponds to following operations:
+It corresponds to the following operations:
.LP
.RS
.nf
.RE
Group
.I daemons
-is created in both hierarchies. In
+is created in both hierarchies. In the
.I cpuacct
hierarchy the group is explicitly mentioned in the configuration
-file. In
+file. In the
.I cpu
-hierarchy is the group created implicitly when
+hierarchy the group is created implicitly when
.I www
is created there. These two groups have nothing in common, for example
they do not share processes and subgroups. Groups
.I www
and
.I ftp
-are created only in
+are created only in the
.I cpu
-hierarchy and are not controlled by
+hierarchy and are not controlled by the
.I cpuacct
subsystem.
}
.RE
.fi
-creates the hierarchy controlled by two subsystems with one group with some
+creates the hierarchy controlled by two subsystems with one group having some
special permissions.
-It corresponds to following operations:
+It corresponds to the following operations:
.LP
.RS
.nf
.fi
.RE
-Users, which are members of the
+Users which are members of the
.I operator
group are allowed to administer the control groups, i.e. create new control
-groups and can move processes between these groups without having root
+groups and move processes between these groups without having root
privileges.
-Members of
+Members of the
.I daemonmaster
-group can move processes to
+group can move processes to the
.I daemons
-control group, but they can not move the process out of the group. Only
+control group, but they can not move the process out of the group. Only the
.I operator
or root can do that.
.SS Keep hierarchies separated
Having multiple hierarchies is perfectly valid and can be useful
in various scenarios. To keeps things clean, do not
-create one group in multiple hierarchies. Examples 4 and 5 show,
+create one group in multiple hierarchies. Examples 4 and 5 show
how unreadable and confusing it can be, especially when reading
-somebody others configuration file.
+somebody elses configuration file.
.SS Explicit is better than implicit
.B libcgroup
-can implicitly create groups which are needed for creation of
+can implicitly create groups which are needed for the creation of
configured subgroups. This may be useful and save some typing in
simple scenarios. When it comes to multiple hierarchies, it's
better to explicitly specify all groups and all controllers
cgconfigparser (8)
.SH BUGS
-Parameter values can be only single string without spaces.
+Parameter values must be single strings without spaces.
Parsing of quoted strings is not implemented.
.SH
.B -l, --load=FILE
Parses the control groups configuration file
Sets up the control group file system
-defined by the configuration file and mount
-mounts points described by the configuration file.
+defined by the configuration file and mounts
+mount points defined by the configuration file.
The format of the file is described in
\fBcgconfig.conf\fR.
.LP
.SH SEE ALSO
cgconfig.conf (5)
-
-
-
-
\fB-g\fR <\fIcontrollers>:<path\fR> [\fB-g\fR ...]
.SH DESCRIPTION
-The command creates new cgroup(s) defined by option
+The command creates new cgroup(s) defined by the options
\fB-g\fR.
.TP
.B -a <agid>:<auid>
-defines the name of the user and the group, which owns the
+defines the name of the user and the group which own the
rest of the defined control group’s files. These users are
allowed to set subsystem parameters and create subgroups.
The default value is the same as has the parent cgroup.
.TP
.B -d, --dperm mode
-sets the permission mode of control groups directory.
-The mode have to be set using octal numbers e.g.
+sets the permissions of a control groups directory.
+The permissions needs to be specified as octal numbers e.g.
\fB-d 775\fR.
.TP
.B -f, --fperm mode
-sets the permission mode of control groups files.
-The mode have to be set using octal numbers e.g.
+sets the permissions of the control groups files.
+The permissions needs to be specified as octal numbers e.g.
\fB-f 775\fR.
.TP
.B -g <controllers>:<path>
-defines control groups which will be added.
+defines control groups to be added.
\fBcontrollers\fR is a list of controllers and
\fBpath\fR is the relative path to control groups
in the given controllers list. This option can be specified
.SH SEE ALSO
cgrules.conf (5)
cgexec (1)
-cgclassify (1)
\ No newline at end of file
+cgclassify (1)
.TP
.B [-g] <controllers>:<path>
-Defines control group to delete. There can be multiple control
-groups specified.
+Defines the control group to delete. Multiple control groups nay be
+specified.
.B -g
is optional.
.SH DESCRIPTION
The \fBcgexec\fR
program executes the task \fBcommand\fR
-with arguments \fBarguments\fR in given control groups.
+with arguments \fBarguments\fR in the given control groups.
.TP
.B -g <controllers>:<path>
-defines control groups in which the task will be run.
+defines the control groups in which the task will be run.
\fBcontrollers\fR is a list of controllers and
\fBpath\fR is the relative path to control groups
in the given controllers list.
define multiple pairs of lists of controllers
and relative paths.
Instead of the list of all mounted controllers,
-wildcard \fBb"*b"\fR can be used.
+the wildcard \fBb"*b"\fR can be used.
-If this option is not used then
-\fBcgexec\fR will automatically place the task to the right
+If this option is not used,
+\fBcgexec\fR will automatically place the task in the right
cgroup based on \fB/etc/cgrules.conf\fR.
.TP
.B --sticky
If running the task \fBcommand\fR with this option, the daemon of
service cgred (cgrulesengd process) does not change both the task
-of the \fBcommand\fR and the children tasks. Without this option,
+of the \fBcommand\fR and the child tasks. Without this option,
the daemon does not change the task of the \fBcommand\fR but it
-changes the children tasks to the right cgroup based on
+changes the child tasks to the right cgroup based on
\fB/etc/cgrules.conf\fR automatically.
.LP
[\fB-g\fR <\fIcontroller\fR>] [\fB-a\fR] <\fBcgroup_path\fR> ...
.SH DESCRIPTION
-The command prints the parameter(s) of input cgroup(s).
-If there is not set any controller or variable,
-then values of all possible variables are displayed.
+Prints the parameter(s) of input cgroup(s).
+If neither controller nor variable are specified,
+the values of all possible variables are displayed.
.TP
.B <path>
.TP
.B -a, --all
-print the variables for all controllers which consists given cgroup
+print the variables for all controllers which consist in the given cgroup
.TP
.B -n
-do not print headers, i.e. name of groups.
+do not print headers, i.e. names of groups.
.TP
.B -v, --values-only
.SH DESCRIPTION
\fBcgrulesengd\fR is a daemon, which distributes processes to control groups. When
-any process changes its effective UID or GID, \fBcgrulesengd\fR inspects list
-of rules loaded from \fIcgrules.conf\fR file and moves the process to
+any process changes its effective UID or GID, \fBcgrulesengd\fR inspects the list
+of rules loaded from the \fIcgrules.conf\fR file and moves the process to
the appropriate control group.
-The list of rules is read during the daemon startup and are cached in daemon's memory.
+The list of rules is read during the daemon startup is are cached in the daemon's memory.
The daemon reloads the list of rules when it receives SIGUSR2 signal.
-The daemon opens a standard unix socket to receive 'sticky' requests from
-cgexec tool.
+The daemon opens a standard unix socket to receive 'sticky' requests from \fBcgexec\fR.
.SH OPTIONS
.TP
.TP
.B -f <path>|--logfile=<path>
Write log messages to the given log file. When '-' is used as <path>, log messages
-are written to the standard output. Both '\fB-f\fR' and '\fB-s\fR' can be used together then logs
-are sent to both destinations.
+are written to the standard output. If '\fB-f\fR' and '\fB-s\fR' are used together,
+the logs are sent to both destinations.
+
.TP
.B -s[facility]|--syslog=[facility]
-Write log messages to syslog. The default facility is DAEMON. Both '\fB-f\fR'
-and '\fB-s\fR' can be used together then logs are sent to both destinations.
+Write log messages to syslog. The default facility is DAEMON. If '\fB-f\fR'
+and '\fB-s\fR' are used together, the logs are sent to both destinations.
.TP
.B -n|--nodaemon
-Don't fork the daemon, stay in foreground.
+Don't fork the daemon, stay in the foreground.
.TP
.B -v|--verbose
-Display more log messages. This option can be used twice to enable even more log
+Display more log messages. This option can be used twice to enable more verbose log
messages.
.TP
.B -q|--quiet
Display less log messages. This option can be used twice to enable even less log
-messages and log errors only.
+messages and to only log errors.
.TP
.B -Q|--nolog
Disable logging.
.TP
.B -u <user>|--socket-user=<user>
.B -g <group>|--socket-group=<group>
-Set owner of cgrulesengd socket. It assumes that cgexec tool runs with proper
-suid permissions so it can write to the socket when cgexec --sticky is used.
+Set the owner of cgrulesengd socket. Assumes that \fBcgexec\fR runs with proper
+suid permissions so it can write to the socket when \fBcgexec\fR --sticky is used.
.SH FILES
.LP
.PD .1v
\fBcgset\fR \fB--copy-from\fR <\fIsource_cgrup_path\fR> <\fBcgroup_path\fR> ...
.SH DESCRIPTION
-The command set the parameters of input cgroup(s).
+Set the parameters of input cgroups.
.TP
.B <path>
.TP
.B -r <name=value>
-defines name of the file to set and
+defines the name of the file to set and
the value which should be written to that file.
This parameter can be used multiple times.
.TP
.B -copy-from <source_cgrup_path>
-defines name of cgroup whose parameters will be
-copied to input cgroup.
+defines the name of the cgroup whose parameters will be
+copied to the input cgroup.
.SH SEE ALSO
cgrules.conf (1), cgcreate (1), cgget (1)
[\fB-w\fR \fIfile\fR] [\fB-f\fR \fIoutput_file\fR] [\fBcontroller\fR] [...]
.SH DESCRIPTION
-
\fBcgsnapshot\fR
generates the cgconfig compatible configuration file
-for given controllers.
+for the given controllers.
If no controller is set, then
cgsnapshot shows all mounted hierarchies.
-The output is in the same format as
+The output is in the same format as the
.B cgconfig.conf
configuration file.
.TP
.B -b file
-Display only variables from blacklist.
+Display only variables from the blacklist.
The default location of the blacklist is
.B /etc/cgsnapshot_blacklist.conf.
-This list contains all variables which should be ignored by
+This list contains all variables which should be ignored by the
.B cgsnapshot
-tool.
-If the variable is blacklisted, then it will not be displayed.
-If it is not present on the blacklist, then the whitelist
+.
+If the variable is blacklisted, it will not be displayed.
+If it is not present on the blacklist, the whitelist
is checked.
.TP
Set the blacklist configuration file.
This list contains all variables which should be displayed by
.B cgsnapshot
-tool.
-If the variable is not blacklisted then whitelist is checked.
-If the variable is on the whitelist, then it is displayed by
+.
+If the variable is not blacklisted, the whitelist is checked.
+If the variable is on the whitelist, it is displayed by
.B cgsnapshot
-tool.
-If the variable is not on the whitelist, then
-the variable is displayed and warning message is produced.
+.
+If the variable is not on the whitelist,
+the variable is displayed and a warning message is produced.
By default the whitelist is not used.
-The warning message can be omitted using
+The warning message can be omitted using the
.B -s, --silent
flag.
-If
+If the
.B -t, --strict
-flag is used then the variable which is not on whitelist is
+flag is used, the variable which is not on the whitelist is
not displayed.
.TP
.B controller
-defines controller whose hierarchies will be
+defines the controller whose hierarchies will be
output
.SH FILES
.TP
.B /etc/cgsnapshot_blacklist.conf
-default location of the blacklist
+default blacklist
.TP
.B /etc/cgsnapshot_whitelist.conf
-default location of the whitelist
+default whitelist
.TP
.B /etc/cgconfig.conf
\fBlscgroup\fR [\fB-h|--help\fR]
.SH DESCRIPTION
-The command list all/chosen cgroups.
+List all/chosen cgroups.
.TP
.B <controllers>:<path>
-defines control groups which subgroups will be shown.
-If this parameter is not used then the command
-list all cgroups which are present.
+defines the control groups whoose subgroups will be shown.
+If this parameter is not used, the command will
+list all existing cgroups.
.SH SEE ALSO
lssubsys (1), cgcreate (1), cgdelete (1),
\fBlssubsys\fR [\fB-h|--help\fR]
.SH DESCRIPTION
-
-The command list hierarchies containing
-the given subsystem(s) if no subsystem is defined then it
+\fBlssubsys\fR list the hierarchies containing
+the given subsystem(s). If no subsystem is defined, it
displays all mounted hierarchies.
.TP
.B controller
-defines subsystem whose hierarchy is shown.
-If this parameter is not used then the command
+defines the subsystem whose hierarchy is shown.
+If this parameter is not used, the command will
list all mounted subsystems.
.TP
.TP
.B -a, --all
-Display all subsystems (including not mounted ones).
+Display all subsystems (including unmounted ones).
.TP
.B -i, --hierarchies
-Display attached hierarchy number, if the subsystem is in a hierarchy.
+Display the attached hierarchy number if the subsystem is in a hierarchy.
If the option
.B -m
-is used too, then the hierarchy number is shown only for not mounted hierarchies.
+is also used, the hierarchy number is shown only for unmounted hierarchies.
.TP
.B -h, --help
Display help and exit.
.SH EXAMPLE
-Command
+The command
.B lssubsys -am
-lists all subsystems which are present on the system,
-mounted ones have attached the mount point:
+lists all subsystems which are present in the system,
+mounted ones will be shown with their mount point:
.RS
.nf
$ lssubsys -am
.fi
.RE
.LP
-Command
+The command
.B lssubsys -ami
-lists all subsystems which are present on the system,
-mounted subsystems have attached the mount point,
-not mounted ones which are in some hierarchy have attached the hierarchy number:
+lists all subsystems which are present in the system,
+mounted subsystems are listed with their mount points,
+unmounted ones which are in a hierarchy are listed with their hierarchy number:
.RS
.nf
$ lssubsys -ami
projects / thirdparty / libcgroup.git / commitdiff
