diff options
| -rw-r--r-- | DISTRO_PORTING | 19 | ||||
| -rw-r--r-- | README | 18 | ||||
| -rw-r--r-- | configure.ac | 3 | ||||
| -rw-r--r-- | man/sd_bus_default.xml | 70 | ||||
| -rw-r--r-- | src/shared/efivars.c | 14 |
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 @@ -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; |