diff options
author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2023-05-31 16:26:14 +0200 |
---|---|---|
committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2023-07-13 10:47:12 +0200 |
commit | a0043bfa51281c2374878e2a98cf2a3ee10fd92c (patch) | |
tree | 6180d045eb95c8e8b58911fd2bcfb1de47722e69 /src/core/execute.c | |
parent | Revert "pid1: order units using TTYVHangup= after vconsole setup" (diff) | |
download | systemd-a0043bfa51281c2374878e2a98cf2a3ee10fd92c.tar.xz systemd-a0043bfa51281c2374878e2a98cf2a3ee10fd92c.zip |
pid1,vconsole-setup: take a lock for the console device
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.
e019ea738d63d5f7803f378f8bd3e074d66be08f 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 cea32691c313b2dab91cef986d08f309edeb4a40 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. 8eb668b9ab2f7627a89c95ffd61350ee9d416da1 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.
Diffstat (limited to 'src/core/execute.c')
-rw-r--r-- | src/core/execute.c | 39 |
1 files changed, 24 insertions, 15 deletions
diff --git a/src/core/execute.c b/src/core/execute.c index 3a0d289fa5..246c151ebc 100644 --- a/src/core/execute.c +++ b/src/core/execute.c @@ -268,25 +268,34 @@ static int exec_context_tty_size(const ExecContext *context, unsigned *ret_rows, } static void exec_context_tty_reset(const ExecContext *context, const ExecParameters *p) { - const char *path; + _cleanup_close_ int fd = -EBADF; + const char *path = exec_context_tty_path(ASSERT_PTR(context)); - assert(context); + /* Take a lock around the device for the duration of the setup that we do here. + * systemd-vconsole-setup.service also takes the lock to avoid being interrupted. + * We open a new fd that will be closed automatically, and operate on it for convenience. + */ - path = exec_context_tty_path(context); + if (p && p->stdin_fd >= 0) { + fd = xopenat_lock(p->stdin_fd, NULL, + O_RDONLY|O_CLOEXEC|O_NONBLOCK|O_NOCTTY, 0, 0, LOCK_BSD, LOCK_EX); + if (fd < 0) + return; + } else if (path) { + fd = open_terminal(path, O_RDWR|O_NOCTTY|O_CLOEXEC|O_NONBLOCK); + if (fd < 0) + return; - if (context->tty_vhangup) { - if (p && p->stdin_fd >= 0) - (void) terminal_vhangup_fd(p->stdin_fd); - else if (path) - (void) terminal_vhangup(path); - } + if (lock_generic(fd, LOCK_BSD, LOCK_EX) < 0) + return; + } else + return; /* nothing to do */ - if (context->tty_reset) { - if (p && p->stdin_fd >= 0) - (void) reset_terminal_fd(p->stdin_fd, true); - else if (path) - (void) reset_terminal(path); - } + if (context->tty_vhangup) + (void) terminal_vhangup_fd(fd); + + if (context->tty_reset) + (void) reset_terminal_fd(fd, true); if (p && p->stdin_fd >= 0) { unsigned rows = context->tty_rows, cols = context->tty_cols; |