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

man: fix few spelling errors 

Reported by Fossies.org.
This commit is contained in:
Frantisek Sumsal 2020-05-01 18:51:33 +02:00 committed by Zbigniew Jędrzejewski-Szmek
parent 2e4086060b
commit 2d4f8cf467
3 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
man/sd_bus_message_open_container.xml
View File

@ -63,7 +63,7 @@
<citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>
and similar functions. Containers behave like a stack. To nest containers inside each other, call and similar functions. Containers behave like a stack. To nest containers inside each other, call
<function>sd_bus_message_open_container()</function> multiple times without calling <function>sd_bus_message_open_container()</function> multiple times without calling
<function>sd_bus_message_close_container()</function> inbetween. Each container will be nested inside the <function>sd_bus_message_close_container()</function> in between. Each container will be nested inside the
previous container. <parameter>type</parameter> represents the container type and should be one of previous container. <parameter>type</parameter> represents the container type and should be one of
<literal>r</literal>, <literal>a</literal>, <literal>v</literal> or <literal>e</literal> as described in <literal>r</literal>, <literal>a</literal>, <literal>v</literal> or <literal>e</literal> as described in
<citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>. <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>.

2
man/sd_notify.xml
View File

@ -272,7 +272,7 @@
<term>BARRIER=1</term> <term>BARRIER=1</term>
<listitem><para>Tells the service manager that the client is explicitly requesting synchronization by means of <listitem><para>Tells the service manager that the client is explicitly requesting synchronization by means of
closing the file descriptor sent with this command. The service manager gurantees that the processing of a <varname> closing the file descriptor sent with this command. The service manager guarantees that the processing of a <varname>
BARRIER=1</varname> command will only happen after all previous notification messages sent before this command BARRIER=1</varname> command will only happen after all previous notification messages sent before this command
have been processed. Hence, this command accompanied with a single file descriptor can be used to synchronize have been processed. Hence, this command accompanied with a single file descriptor can be used to synchronize
against reception of all previous status messages. Note that this command cannot be mixed with other notifications, against reception of all previous status messages. Note that this command cannot be mixed with other notifications,

2
src/core/main.c
View File

@ -1220,7 +1220,7 @@ static int bump_rlimit_memlock(struct rlimit *saved_rlimit) {
assert_cc(RLIM_INFINITY > 0); assert_cc(RLIM_INFINITY > 0);
mm = physical_memory() / 8; /* Let's scale how much we allow to be locked by the amount of physical mm = physical_memory() / 8; /* Let's scale how much we allow to be locked by the amount of physical
* RAM. We allow an eigth to be locked by us, just to pick a value. */ * RAM. We allow an eighth to be locked by us, just to pick a value. */
new_rlimit = (struct rlimit) { new_rlimit = (struct rlimit) {
.rlim_cur = MAX3(HIGH_RLIMIT_MEMLOCK, saved_rlimit->rlim_cur, mm), .rlim_cur = MAX3(HIGH_RLIMIT_MEMLOCK, saved_rlimit->rlim_cur, mm),