picnoir/Systemd
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge pull request #4414 from poettering/consolesakcomment

Browse source 
three minor fixes: document /dev/console/SAK handling + another cgroups wording fix + document User= default
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2016-10-20 09:35:40 -04:00 committed by GitHub
parent 332c0d48a9 47da760efd
commit 8fdea26c94
4 changed files with 24 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
man/machinectl.xml
View file

@ -343,18 +343,13 @@
<varlistentry>
<term><command>show</command> [<replaceable>NAME</replaceable>...]</term>
<listitem><para>Show properties of one or more registered
virtual machines or containers or the manager itself. If no
argument is specified, properties of the manager will be
shown. If a NAME is specified, properties of this virtual
machine or container are shown. By default, empty properties
are suppressed. Use <option>--all</option> to show those too.
To select specific properties to show, use
<option>--property=</option>. This command is intended to be
used whenever computer-parsable output is required, and does
not print the cgroup tree or journal entries. Use
<command>status</command> if you are looking for formatted
human-readable output.</para></listitem>
<listitem><para>Show properties of one or more registered virtual machines or containers or the manager
itself. If no argument is specified, properties of the manager will be shown. If a NAME is specified,
properties of this virtual machine or container are shown. By default, empty properties are suppressed. Use
<option>--all</option> to show those too. To select specific properties to show, use
<option>--property=</option>. This command is intended to be used whenever computer-parsable output is
required, and does not print the control group tree or journal entries. Use <command>status</command> if you
are looking for formatted human-readable output.</para></listitem>
</varlistentry>
<varlistentry>

9
man/systemd.exec.xml
View file

@ -141,8 +141,13 @@
<term><varname>Group=</varname></term>
<listitem><para>Set the UNIX user or group that the processes are executed as, respectively. Takes a single
user or group name, or numeric ID as argument. If no group is set, the default group of the user is used. This
setting does not affect commands whose command line is prefixed with <literal>+</literal>.</para></listitem>
user or group name, or numeric ID as argument. For system services (services run by the system service manager,
i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
<command>systemd --user</command>), the default is <literal>root</literal>, but <varname>User=</varname> may be
used to specify a different user. For user services of any other user, switching user identity is not
permitted, hence the only valid setting is the same user the user's service manager is running as. If no group
is set, the default group of the user is used. This setting does not affect commands whose command line is
prefixed with <literal>+</literal>.</para></listitem>
</varlistentry>
<varlistentry>

5
src/core/show-status.c
View file

@ -61,6 +61,11 @@ int status_vprintf(const char *status, bool ellipse, bool ephemeral, const char
if (vasprintf(&s, format, ap) < 0)
return log_oom();
/* Before you ask: yes, on purpose we open/close the console for each status line we write individually. This
* is a good strategy to avoid PID 1 getting killed by the kernel's SAK concept (it doesn't fix this entirely,
* but minimizes the time window the kernel might end up killing PID 1 due to SAK). It also makes things easier
* for us so that we don't have to recover from hangups and suchlike triggered on the console. */
fd = open_terminal("/dev/console", O_WRONLY|O_NOCTTY|O_CLOEXEC);
if (fd < 0)
return fd;

5
src/journal/journald-console.c
View file

@ -102,6 +102,11 @@ void server_forward_console(
tty = s->tty_path ? s->tty_path : "/dev/console";
/* Before you ask: yes, on purpose we open/close the console for each log line we write individually. This is a
* good strategy to avoid journald getting killed by the kernel's SAK concept (it doesn't fix this entirely,
* but minimizes the time window the kernel might end up killing journald due to SAK). It also makes things
* easier for us so that we don't have to recover from hangups and suchlike triggered on the console. */
fd = open_terminal(tty, O_WRONLY|O_NOCTTY|O_CLOEXEC);
if (fd < 0) {
log_debug_errno(fd, "Failed to open %s for logging: %m", tty);