Paul Cercueil [Mon, 15 Jun 2020 10:54:28 +0000 (12:54 +0200)]
sd-boot: Add small comments after device-specific key macros
The key macros added in commit 6fe95d3020 look strange at first sight.
Add a comment with just the tablet name after each line, so that it's
obvious that these lines address device-specific issues of the EFI
firmware, and not broken/old code.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
network: clean-up DHCP lease server data configuration
This is an attempt to clean up the POP3/SMTP/LPR/… DHCP lease server
data logic in networkd. This reduces code duplication and fixes a number
of bugs.
This removes any support for collecting POP3/SMPT/LPR servers acquired
via local DHCP client releases since noone uses that, and given how old
these protocols are I doubt this will change. It keeps support for
configuring them for the dhcp server however.
The differences between the DNS/NTP/SIP/POP3/SMTP/LPR configuration
logics are minimized.
This removes the relevant symbols from sd-network.h (which is an
internal API only at this point after all).
This is unfortunately not well test, given the old code for this had
barely any tests. But the new code should not perform worse at least,
and allow us to release, since it corrects some interfaces visible in
the .network configuration format.
Luca Boccassi [Mon, 15 Jun 2020 18:50:56 +0000 (19:50 +0100)]
efi: use stub for cache_efi_options_variable if !ENABLE_EFI
../src/core/main.c: In function 'main':
../src/core/main.c:2637:32: error: implicit declaration of function 'cache_efi_options_variable'; did you mean 'systemd_efi_options_variable'? [-Werror=implicit-function-declaration]
(void) cache_efi_options_variable();
^~~~~~~~~~~~~~~~~~~~~~~~~~
systemd_efi_options_variable
Strictly speaking this is a compat breakage, but given the tool was
added only in the last release, let's try to sail under the radar, and
fix this early before anyone notices it wasn't supported always.
Kai-Heng Feng [Thu, 11 Jun 2020 13:32:12 +0000 (21:32 +0800)]
hwdb: Mask rfkill event from intel-hid on HP platforms
HP spec mandates the hp-wireless driver as canonical source of rfkill
event, so mask the rfkill event from intel-hid to avoid double rfkill
events fired from a single hotkey press.
Paul Cercueil [Sun, 14 Jun 2020 10:51:36 +0000 (12:51 +0200)]
sd-boot: Work around malformed CR key code
When a key is pressed, the EFI firmware gives us a 64-bit word that
contains the modifier key code in the upper 32 bits, the scan code in
the middle 16 bits, and a unicode character in the low 16 bits.
Some bogus EFI firmwares will put the unicode character in the scan code
area, for instance on the EZpad mini 4s tablet.
Others will even put the unicode character in both the scan code and
unicode areas. This is the case for instance on the Teclast X98+ II
tablet.
Add workarounds for these corner cases, only for the carriage return key
right now. Some more workarounds may be needed, e.g. for volume keys,
but I cannot test it.
Partially fixes #8466.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
This page should be in section 8, like all .service descriptions.
Also extend the text a bit to make it clearer that systemd --user is the same
executable but running in a different mode (which might be certainly a bit
confusing to users.)
efi: Skip parsing SystemdOptions if there's an error getting it.
The original logic was logging an "ignored" debug message, but it was still
going ahead and calling proc_cmdline_parse_given() on the NULL line. Fix that
to skip that explicitly when the EFI variable wasn't really read.
man: Document the crypttab keyfile syntax specifying a device
Feature introduced in 50d2eba27b9bfc77ef6b40e5721713846815418b. Also documented
as part of the kernel parameter syntax in systemd-cryptsetup-generator(8), but
should also be documented here as part of the overall file syntax.
Tomáš Pospíšek [Sun, 14 Jun 2020 08:43:06 +0000 (10:43 +0200)]
Improve message for scheduled shutdown or reboot
Depending on if the system has been scheduled for shutdown or for reboot pring the corresponding message (and not only "Shutdown"). Prtinting the "wrong" message when rebooting will mislead and panic people. I get these messages via cron from remote servers and it would be bad if those systems actually *did* shut down, as the email from cron is telling me. Those messages cause an adrenalin spike in our team, which wouldn't happen, if the message was "correct"
It stopped making sense when automake support was dropped and python started
being required to perform a build.
Follow-up for 72cdb3e783174dcf9223a49f03e3b0e2ca95ddb8.
update-man-rules: properly filter out directives index again
When directives-template.xml was created in 282230882cd0fc49b5377349f2aee22a1c9dd159,
this generator started picking it up. Let's filter it out properly again,
and also simply the filter while at it.
efi: Cache contents of EFI variable SystemdOptions
Cache it early in startup of the system manager, right after `/run/systemd` is
created, so that further access to it can be done without accessing the EFI
filesystem at all.
Dan Streetman [Fri, 12 Jun 2020 22:23:15 +0000 (18:23 -0400)]
test: in test_bridge_configure_without_carrier, ignore setup_state
This test is failing becuase the setup state isn't reaching 'configured'
for unknown reasons; ignore the setup state for now to prevent failures
of CI until the reason can be investigated.
half of find_hibernation_location() logged at debug level, the other
half logged at error level, and the third half didn't log at all.
Let's clean this up somewhat. Since can_sleep() is probably more
a library-style function let's downgrade everything to LOG_DEBUG and
then make sure sleep.c logs at error level, as the main program.
meson: build standalone version of systemd-tmpfiles
Use -Dstandalone-binaries=yes to enable building and installing this standalone
version of the binary without a dependency on the systemd-shared solib.
Also move the list of sources for systemd-tmpfiles to its own meson.build file.
meson: add a new -Dstandalone-binaries=true option
This adds an option to build standalone binaries that do not depend on the
systemd-shared library. This option can be handy to build binaries that can be
useful on a non-systemd system, binaries such as systemd-sysusers and
systemd-tmpfiles have been previously requested, but installing them with all
the required dependencies pulls in too much code that isn't really relevant for
those use cases. The standalone use case is also relevant in containers, where
minimizing the size of the container image is quite relevant.
For now, only `systemd-sysusers` is also built as a standalone binary.
The standalone binaries are installed as `/usr/bin/%{name}.standalone`, the
packaging system is reponsible for renaming those into the correct names
during the packaging step. RPM is able to do so with RemovePathPostfixes:
The default behavior is to build shared binaries only, since this option is
mainly intended for building distribution packages.
Tested that a proper separate binary is built when using this option and
that having it disabled (or using the default Meson configuration) does not
produce a binary for this option.
* check if /var is a mountpoint - if not, something went wrong. In case
of systemd/systemd#16111 the /failed file was created, because
systemd-cryptsetup failed, but it ended up being empty, making the result
check incorrectly pass
* forward journal messages to console - if we fail to mount /var,
journald won't flush logs to the persistent storage and we end up
empty handed and with no clue what went wrong
For example, without systemd/systemd#16111 and with this patch:
...
[FAILED] Failed to start systemd-cryptsetup@varcrypt.service.
See 'systemctl status systemd-cryptsetup@varcrypt.service' for details.
[DEPEND] Dependency failed for cryptsetup.target.
...
[ 3.882451] systemd-cryptsetup[581]: Key file /etc/varkey is world-readable. This is not a good idea!
[ 3.883946] systemd-cryptsetup[581]: WARNING: Locking directory /run/cryptsetup is missing!
[ 3.884846] systemd-cryptsetup[581]: Failed to load Bitlocker superblock on device /dev/disk/by-uuid/180ba5ef-873b-4018-9968-47c23431f71a: Invalid argument
...
[ 4.099451] sh[606]: + mountpoint /var
[ 4.100025] sh[603]: + systemctl poweroff --no-block
[ 4.101636] systemd[1]: Finished systemd-user-sessions.service.
[ 4.102598] sh[608]: /var is not a mountpoint
[FAILED] Failed to start testsuite-02.service.
David Edmundson [Mon, 8 Jun 2020 21:00:33 +0000 (22:00 +0100)]
docs: Change suffix for desktop applications to support non-transient services
One problem found with the current draft specification is we can't have
an application provide a non-transient systemd service file in a way
that is spec compliant as the service name currently needs to end in a
random token defined by the launcher.
This came up when trying to put DBus activated services into the correct
cgroup. There isn't enough metadata in the DBus service file to know the
correct application ID, and the most intuitive fix is for those
applications to just specify the SystemdService file in the existing
system. They're generally unique for a given user session anyway so
don't need a separate cgroup identifier.
This changes the spec for RANDOM to be optional for services.
It also changes the separator between in services to act like templates.
Ultimately that's what we're trying to recreate with the RANDOM token of
the systemd service and it's a better fit. It's needed as otherwise with
launcher and the random ident being both optional it would be impossible
to get the application ID reliably.
Scopes are unchanged as they don't support templates.
pager: set PR_DEATHSIG for pager to SIGINT rather than SIGTERM
"less" doesn't properly reset its terminal on SIGTERM, it does so only
on SIGINT. Let's thus configure SIGINT instead of SIGTERM.
I think this is something less should fix too, and clean up things
correctly on SIGTERM, too. However, given that we explicitly enable
SIGINT behaviour by passing "K" to $LESS I figure it makes sense if we
also send SIGINT instead of SIGTERM to match it.
unit_choose_id() is about marking one of the aliases of the unit as the main
name. With the preparatory work in previous patches, all aliases of the unit
must have the same instance, so the operation to update the instance is a noop.
core: create socket service instances with the correct name from the start
Upon an incoming connection for an accepting socket, we'd create a unit like
foo@0.service, then figure out that the instance name should be e.g. "0-41-0",
and then add the name foo@0-41-0.service to the unit. This obviously violates
the rule that any service needs to have a constance instance part.
So let's reverse the order: we first determine the instance name and then
create the unit with the correct name from the start.
There are two cases where we don't know the instance name:
- analyze-verify: we just do a quick check that the instance unit can be
created. So let's use a bogus instance string.
- selinux: the code wants to load the service unit to extract the ExecStart path
and query it for the selinux label. Do the same as above.
Note that in both cases it is possible that the real unit that is loaded could
be different than the one with the bogus instance value, for example if there
is a dropin for a specific instance name. We can't do much about this, since we
can't figure out the instance name in advance. The old code had the same
shortcoming.
They were added recently in acd1987a1867fc3390ef2516962b2313cbeb366e. We can
make them more informative by using unit_type_to_string() and not repeating
unit names as much. Also, %m should not be used together with SYNTHETIC_ERRNO().
core: when adding names to unit, require matching instance strings
We would check that the instance is present in both units (or missing in both).
But when it is defined, it should be the same in both. The comment in the code
was explicitly saying that differing instance strings are allowed, but this
mostly seems to be a left-over from old times. The man page is pretty clear:
> the instance (if any) is always uniquely defined for a given unit and all its
> aliases.
So let's add a separate .id field, and only store aliases in the set, and only
create the set if there's at least one alias. This requires a bit of gymnastics
in the code, but I think this optimization is worth the trouble, because we
save one object for many loaded units.
In particular set_complete_move() wasn't very useful because the target
unit would always have at least one name defined, i.e. the optimization to
move the whole set over would never fire.
poll() sets POLLNVAL inside of the poll structures if an invalid fd is
passed. So far we generally didn't check for that, thus not taking
notice of the error. Given that this specific kind of error is generally
indication of a programming error, and given that our code is embedded
into our projects via NSS or because people link against our library,
let's explicitly check for this and convert it to EBADF.
(I ran into a busy loop because of this missing check when some of my
test code accidentally closed an fd it shouldn't close, so this is a
real thing)
In the past we occasionally stumbled upon a build issue which could be
reproduced only with specific optimization level or other compilation
option. Let's try to build the current revision with several most common
compiler options causing such issues to catch them early.
YmrDtnJu [Mon, 25 May 2020 08:46:54 +0000 (10:46 +0200)]
AppArmor: Support for loading a set of pre-compiled profiles at startup time
Let systemd load a set of pre-compiled AppArmor profile files from a policy
cache at /etc/apparmor/earlypolicy. Maintenance of that policy cache must be
done outside of systemd.
After successfully loading the profiles systemd will attempt to change to a
profile named systemd.
If systemd is already confined in a profile, it will not load any profile files
and will not attempt to change it's profile.
If anything goes wrong, systemd will only log failures. It will not fail to
start.
Chris Down [Tue, 9 Jun 2020 13:43:05 +0000 (14:43 +0100)]
doc: Try to clarify automount dependency confusion
Arch recently upgraded systemd to 245.6. Shortly afterwards, users began
reporting[0] that systemd detected an ordering cycle, and they were
unable to log in. The reason they were unable to log in was because of
ordering cycle resolution:
[...]
systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
systemd[1]: sysinit.target: Job systemd-update-done.service/start deleted to break ordering cycle starting with sysinit.target/start
systemd[1]: sysinit.target: Job systemd-journal-catalog-update.service/start deleted to break ordering cycle starting with sysinit.target/start
systemd[1]: sysinit.target: Job local-fs.target/start deleted to break ordering cycle starting with sysinit.target/start
systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
[...]
Whether the resolution did the right thing here or not is a longer-term
discussion, but in the interim we should at least make this distinction
between automount dependencies and mount dependencies clearer in the
documentation, so that users and distribution maintainers know what's
acceptable. In this case Arch actually backed out b3d7aef5 entirely and
released a new version due to the confusion.
Also see https://github.com/systemd/systemd-stable/issues/69.
inaccessible: move inaccessible file nodes to /systemd/ subdir in runtime dir always
Let's make sure $XDG_RUNTIME_DIR for the user instance and /run for the
system instance is always organized the same way: the "inaccessible"
device nodes should be placed in a subdir of either called "systemd" and
a subdir of that called "inaccessible".
This way we can emphasize the common behaviour, and only differ where
really necessary.
On systemd systems we generally don't need to chdir() to root, we don't
need to setup /dev/ ourselves (as PID 1 does that during earliest boot),
and we don't need to set the OOM adjustment values, as that's done via
unit files.
Hence, drop this. if people want to use udev from other init systems
they should do this on their own, I am very sure it's a good thing to do
it from outside of udevd, so that fewer privileges are required by udevd. In
particular the dev_setup() stuff is something that people who build
their own non-systemd distros want to set up themselves anyway, in
particular as they already have to mount devtmpfs themselves anyway.
Note that this only drops stuff that isn't really necessary for testing
stuff, i.e. process properties and settings that don't matter if you
quickly want to invoke udev from a terminal session to test something.
projects / thirdparty / systemd.git / log
