When systemd-firstboot (or any other unit which uses the tty) is started,
systemd will reset the terminal. If systemd-vconsole-setup happens to be
running at that time, it'll error out when it tries to use the vconsole fd and
gets an EIO from ioctl.
e019ea738d was the first fix. It added an
implicit ordering between units using the tty and systemd-vconsole-setup.
(The commit title is wrong. The approach was generalized, but the commit title
wasn't updated.)
Then cea32691c3 was added to restart
systemd-vconsole-setup.service from systemd-firstboot.service. This was OK,
with the ordering in place, systemd-vconsole-setup.service would wait until
systemd-firstboot.service exited. But this wasn't enough, because we want the
key mappings to be loaded immediately after systemd-firstboot writes the
config. 8eb668b9ab implemented that, but actually
reintroduced the original issue. I had to drop the ordering between the two
units because otherwise we'd deadlock, waiting from firstboot for
vconsole-setup which wouldn't start while firstboot was running.
Restarting vconsole-setup.service from systemd-firstboot.service works just
fine, but when vconsole-setup.service is started earlier, it may be interrupted
by systemd-firstboot.service.
To resolve the issue, let's take a lock around the tty device. The reset is
performed after fork, so the (short) delay should not matter too much.
In xopenat_lock() the assert on <path> is dropped so that we can call
xopenat(fd, NULL) to get a copy of the original fd.
Fixes#26908.
This reverts commit e019ea738d.
In the new approach, a lock on /dev/console will be used. This lock will solve
the issue for services which run in early boot. Services which run later are
ordered after sysinit.target, so they'll run much later anyway so this
automatic dependency is not useful. Let's remove it again to make the code
simpler.
"Setup" is a noun, and the expected order is "<adjective> <noun>".
("Set up" is the verb. But we want a noun here, so that we can say
e.g. "Starting Virtual Console Setup".)
Some distributions still use glibc's libcrypt. In that case, libcrypt.pc
does not exist and dependency() will fail.
Also, even if libxcrypt is used, there may not be a symlink
from libcrypt.pc to libxcrypt.pc. So, let's add a secondary name.
Follow-up for d625f717db.
Fixes#28289.
It is marked and named as a script, so add +x otherwise Lintian complains:
W: systemd-tests: script-not-executable [usr/lib/systemd/tests/testdata/units/generator-utils.sh]
When a static null address is requested, e.g. Address=0.0.0.0/24,
then the corresponding Address object owned by Network object has
null address, and previously it did not match any addresses already
assigne to the interface.
Let's search matching Address object when originally it is requested as
the null address.
Then, the address configured with requested as a null address will be
kept on reconfigure.
Fixes#26113.
Request may refer Address object owned by Link, but its broadcast
address or label may be updated by address_equalify(), hence these
fields cannot be used in the hash and compare functions.
Introduce a manual test tool that creates a journal, corrupts it by
flipping bits at given offsets, and then attempts to write to the journal.
In ideal case we should handle this gracefully without any crash or
memory corruption.
With the fix done in PR28215, the unit restart job is created with type JOB_START.
Because of that, it is not properly merged anymore with the old one: the
merged job has state JOB_RUNNING. It should have state JOB_WAITING.
I think that the old job is not cleaned up because we don't go through the failed state.
With this fix, the merged job is properly created with state JOB_WAITING.
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
Luca Boccassi
Christian Hesse
Lily Foster
Frantisek Sumsal
Weblate
Richard Phibel