summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--DISTRO_PORTING19
-rw-r--r--README18
-rw-r--r--configure.ac3
-rw-r--r--man/sd_bus_default.xml70
-rw-r--r--src/shared/efivars.c14
5 files changed, 98 insertions, 26 deletions
diff --git a/DISTRO_PORTING b/DISTRO_PORTING
index d8e9ded943..07aea865be 100644
--- a/DISTRO_PORTING
+++ b/DISTRO_PORTING
@@ -14,6 +14,7 @@ HOWTO:
--with-kbd-loadkeys=
--with-kbd-setfont=
--with-tty-gid=
+ --with-ntp-servers=
2) Try it out. Play around (as an ordinary user) with
'/usr/lib/systemd/systemd --test --system' for a test run
@@ -21,6 +22,24 @@ HOWTO:
print the initial transaction it would execute during boot-up.
This will also inform you about ordering loops and suchlike
+NTP POOL:
+
+ By default, timesyncd uses the Google NTP servers
+ time[1-4].google.com. They serve time that is not standards
+ compliant, and can be up to .5s off. Google does not
+ officially support these servers for the broader
+ audience. Distributions and vendors really should not ship
+ OSes or devices with these NTP servers configured. Instead,
+ please register your own vendor pool at ntp.org and make it
+ the built-in default by passing --with-ntp-servers= to
+ configure. Registering vendor pools is free:
+
+ http://www.pool.ntp.org/en/vendors.html
+
+ Again, if you ship your software or device with the default
+ NTP servers, then you will get served wrong time, and will
+ rely on services that might not be supported for long.
+
CONTRIBUTING UPSTREAM:
We generally do no longer accept distribution-specific
diff --git a/README b/README
index 53220ff3f2..7595949765 100644
--- a/README
+++ b/README
@@ -82,11 +82,11 @@ REQUIREMENTS:
CONFIG_SECCOMP
CONFIG_CHECKPOINT_RESTORE (for the kcmp() syscall)
- Required for CPUShares in resource control unit settings
+ Required for CPUShares= in resource control unit settings
CONFIG_CGROUP_SCHED
CONFIG_FAIR_GROUP_SCHED
- Required for CPUQuota in resource control unit settings
+ Required for CPUQuota= in resource control unit settings
CONFIG_CFS_BANDWIDTH
For systemd-bootchart, several proc debug interfaces are required:
@@ -97,6 +97,15 @@ REQUIREMENTS:
CONFIG_EFIVAR_FS
CONFIG_EFI_PARTITION
+ We recommend to turn off Real-Time group scheduling in the
+ kernel when using systemd. RT group scheduling effectively
+ makes RT scheduling unavailable for most userspace, since it
+ requires explicit assignment of RT budgets to each unit whose
+ processes making use of RT. As there's no sensible way to
+ assign these budgets automatically this cannot really be
+ fixed, and it's best to disable group scheduling hence.
+ CONFIG_RT_GROUP_SCHED=n
+
Note that kernel auditing is broken when used with systemd's
container code. When using systemd in conjunction with
containers, please make sure to either turn off auditing at
@@ -261,6 +270,11 @@ WARNINGS:
false positives will be triggered by code which violates
some rules but is actually safe.
+ Currently, systemd-timesyncd defaults to use the Google NTP
+ servers if not specified otherwise at configure time. You
+ really should not ship an OS or device with this default
+ setting. See DISTRO_PORTING for details.
+
ENGINEERING AND CONSULTING SERVICES:
ENDOCODE <https://endocode.com/> offers professional
engineering and consulting services for systemd. Please
diff --git a/configure.ac b/configure.ac
index 6804e03d07..999f9f84d3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1009,7 +1009,8 @@ AC_ARG_WITH(ntp-servers,
AS_HELP_STRING([--with-ntp-servers=NTPSERVERS],
[Space-separated list of default NTP servers]),
[NTP_SERVERS="$withval"],
- [NTP_SERVERS="time1.google.com time2.google.com time3.google.com time4.google.com"])
+ [NTP_SERVERS="time1.google.com time2.google.com time3.google.com time4.google.com"
+ AC_MSG_WARN([*** Using Google NTP servers. Please do not ship OSes or devices with these default settings. See DISTRO_PORTING for details!])])
AC_DEFINE_UNQUOTED(NTP_SERVERS, ["$NTP_SERVERS"], [Default NTP Servers])
AC_SUBST(NTP_SERVERS)
diff --git a/man/sd_bus_default.xml b/man/sd_bus_default.xml
index 782dfb5706..1cf2cb8f9a 100644
--- a/man/sd_bus_default.xml
+++ b/man/sd_bus_default.xml
@@ -111,9 +111,9 @@
<para><function>sd_bus_default()</function> acquires a bus
connection object to the user bus when invoked in user context, or
to the system bus otherwise. The connection object is associated
- to the calling thread. Each time the function is invoked from the
- same thread the same object is returned, but its reference count
- is increased by one, as long as at least one reference is
+ with the calling thread. Each time the function is invoked from
+ the same thread the same object is returned, but its reference
+ count is increased by one, as long as at least one reference is
kept. When the last reference to the connection is dropped (using
the
<citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
@@ -121,10 +121,11 @@
not automatically terminated when the associated thread ends. It
is important to drop the last reference to the bus connection
explicitly before the thread ends or otherwise the connection will
- be leaked.</para>
+ be leaked. Also, queued but unread or unwritten messages keep the
+ bus referenced, see below.</para>
<para><function>sd_bus_default_user()</function> returns a user
- bus connection object associated to the calling thread.
+ bus connection object associated with the calling thread.
<function>sd_bus_default_system()</function> is similar, but
connects to the system bus. Note that
<function>sd_bus_default()</function> is identical to these two
@@ -193,38 +194,63 @@
</refsect1>
<refsect1>
- <title>Return Value</title>
-
- <para>On success, these calls return 0 or a positive
- integer. On failure, these calls return a negative
- errno-style error code.</para>
- </refsect1>
-
- <refsect1>
<title>Reference ownership</title>
<para>The functions <function>sd_bus_open()</function>,
<function>sd_bus_open_user()</function>,
<function>sd_bus_open_system()</function>,
<function>sd_bus_open_system_remote()</function>, and
<function>sd_bus_open_system_machine()</function> return a new
- object and the caller owns the sole reference. When not needed
- anymore, this reference should be destroyed with
+ connection object and the caller owns the sole reference. When not
+ needed anymore, this reference should be destroyed with
<citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
</para>
<para>The functions <function>sd_bus_default()</function>,
<function>sd_bus_default_user()</function> and
<function>sd_bus_default_system()</function> do not necessarily
- create a new object, but increase the connection reference by
- one. Use
+ create a new object, but increase the connection reference of an
+ existing connection object by one. Use
<citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
to drop the reference.</para>
- <para>Queued messages also keep a reference to the bus. For this reason, just
- because no application is having a reference to the bus does not mean that
- the bus object will be destroyed. Until all the messages are sent, the bus object
- will stay alive. <function>sd_bus_flush</function> can be used to send all the
- queued messages so they drop their references.</para>
+ <para>Queued but unwritten/unread messages also keep a reference
+ to their bus connection object. For this reason, even if an
+ application dropped all references to a bus connection it might
+ not get destroyed right-away. Until all incoming queued
+ messages are read, and until all outgoing unwritten messages are
+ written, the bus object will stay
+ alive. <function>sd_bus_flush()</function> may be used to write
+ all outgoing queued messages so they drop their references. To
+ flush the unread incoming messages use
+ <function>sd_bus_close()</function>, which will also close the bus
+ connection. When using the default bus logic it is a good idea to
+ first invoke <function>sd_bus_flush()</function> followed by
+ <function>sd_bus_close()</function> when a thread or process
+ terminates, and thus its bus connection object should be
+ freed.</para>
+
+ <para>The life-cycle of the default bus connection should be the
+ responsibility of the code that creates/owns the thread the
+ default bus connection object is associated with. Library code
+ should neither call <function>sd_bus_flush()</function> nor
+ <function>sd_bus_close()</function> on default bus objects unless
+ it does so in its own private, self-allocated thread. Library code
+ should not use the default bus object in other threads unless it
+ is clear that the program using it will life-cycle the bus
+ connection object and flush and close it before exiting from the
+ thread. In libraries where it is not clear that the calling
+ program will life-cycle the bus connection object it is hence
+ recommended to use <function>sd_bus_open_system()</function>
+ instead of <function>sd_bus_default_system()</function> and
+ related calls.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Return Value</title>
+
+ <para>On success, these calls return 0 or a positive
+ integer. On failure, these calls return a negative
+ errno-style error code.</para>
</refsect1>
<refsect1>
diff --git a/src/shared/efivars.c b/src/shared/efivars.c
index 0d6ecf52cf..347cd30b09 100644
--- a/src/shared/efivars.c
+++ b/src/shared/efivars.c
@@ -125,7 +125,19 @@ static int get_os_indications(uint64_t *os_indication) {
return r;
r = efi_get_variable(EFI_VENDOR_GLOBAL, "OsIndications", NULL, &v, &s);
- if (r < 0)
+ if (r == -ENOENT) {
+ /* Some firmware implementations that do support
+ * OsIndications and report that with
+ * OsIndicationsSupported will remove the
+ * OsIndications variable when it is unset. Let's
+ * pretend it's 0 then, to hide this implementation
+ * detail. Note that this call will return -ENOENT
+ * then only if the support for OsIndications is
+ * missing entirely, as determined by
+ * efi_reboot_to_firmware_supported() above. */
+ *os_indication = 0;
+ return 0;
+ } else if (r < 0)
return r;
else if (s != sizeof(uint64_t))
return -EINVAL;